search

cyberark / conjur

CyberArk Conjur automatically secures secrets used by privileged users and machine identities
https://conjur.org
Other
782 stars 124 forks source link

Design for single-use-token (SUT) authenticator #2971

Closed szh closed 1 year ago

szh commented 1 year ago

Desired Outcome

Our first pass at a UI-PSM integration was rejected for security reasons and the more secure option likely requires us to create a new token authenticator for Conjur. Create a solution design for that and figure out how large of an effort it would be.

Implemented Changes

Created a solution design document for a new single-use-token (SUT) authenticator

Connected Issue/Story

CyberArk internal issue ID: CNJR-2514

jvanderhoof commented 1 year ago

I don't love the term authn-sut (looks too much like a potentially derogatory word). How about something like authn-singleuse, authn-single-use or authn-token?

jvanderhoof commented 1 year ago

Although it likely makes sense to limit the initial scope to Conjur Users, it's important to enable this functionality for Hosts as well. There are a number of interesting use cases that will be enabled with support for SUT for hosts.

For awareness, there is a push to remove the API key as an authentication mechanism. When that fully comes to fruition, I suspect that adding an authn-apikey authenticator is the best way to re-enable the use of API keys for authentication.

As a final note, the decoupling of identity from authentication will likely require is to support "default" authentication mechanisms. It's quite possible we can support this behavior via Policy Factories, but we may need a more native solution at some point.

szh commented 1 year ago

I don't love the term authn-sut (looks too much like a potentially derogatory word). How about something like authn-singleuse, authn-single-use or authn-token?

I feel that token is too generic and confusing, since we already have auth tokens. Maybe authn-nonce or something similar?

szh commented 1 year ago

Although it likely makes sense to limit the initial scope to Conjur Users, it's important to enable this functionality for Hosts as well. There are a number of interesting use cases that will be enabled with support for SUT for hosts.

Absolutely, I see no reason not to allow this for hosts.

For awareness, there is a push to remove the API key as an authentication mechanism. When that fully comes to fruition, I suspect that adding an authn-apikey authenticator is the best way to re-enable the use of API keys for authentication.

To clarify, are you saying that API key authentication will no longer be enabled by default, and it'll need to be moved to an authn-apikey authenticator that will need to be enabled manually? How will this affect the single use token authenticator?

As a final note, the decoupling of identity from authentication will likely require is to support "default" authentication mechanisms. It's quite possible we can support this behavior via Policy Factories, but we may need a more native solution at some point.

Again to clarify, do you mean we'll want to have this authenticator enabled by default without requiring the administrator to create a policy for it?

codeclimate[bot] commented 1 year ago

Code Climate has analyzed commit 88d44511 and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 100.0% (50% is the threshold).

This pull request will bring the total coverage in the repository to 88.4% (-0.1% change).

View more on Code Climate.

szh commented 1 year ago

Moved to GitHub Enterprise. See PR #8 in the repo there.