Conjur supports resources which authenticate without an API key

jvanderhoof commented 4 years ago

Overview

The proposed solution for this is to introduce a new policy attribute for roles (e.g. host, user) called api_key_enabled. This attribute will default to true if not explicitly provided, and will dictate whether Conjur:

Generates an API key when the role is created by policy: This is relevant for newly created roles. If api_key_enabled: false, then this role will never receive a randomly generated API key.
Allows an API key to be rotated for a role: This prevents an API key from being created after the initial role creation.
Allows an API key to be validated for a role: This covers the case when an existing role (that has an API key) is updated to set api_key_enabled to false. In this case the API key already exists, but the Role model will always return false for api_key_valid?.

Scenarios

Scenario	`api_key_enabled: true`	`api_key_enabled: false`
Role (`host`/`user`) created	API key is generated and stored in the database.	API key in the database is set to `null`.
Rotate role key	API key is rotated and new value is stored in database.	Value in database is unchanged and server responds with an error that keys are disabled for the role and cannot be rotated.
Default authentication `authn`	API in request is validated against key in database.	API key validation always returns false and authentication fails.
Update role to set `api_key_enabled: true`	No change	If key is `null`, generate value and store it in database.
Update role to set `api_key_enabled: false`	Set api key in DB to `null`	No change to database.

Prototype

Branches for prototype exploration for this proposal are available at:

Areas not covered in prototype

Error messages (specifically for CLI) when attempting to authenticate as a role that has no API key.
Impact on docs for authenticators (to recommend adding this attribute).

Rough Effort Estimate

Code Changes: 18 days
Docs Updates: 8 days

InbalZilberman commented 4 years ago

@jvanderhoof thank you! a blessed change

I think that the error flows are very important for a comprehensive flows and UX. Can you please address maybe in highlevel how do you see these flows?
How are we keeping backward compatibility? How will this change affect DAP?
Have you considered having the same behavior as apps or clients? In addition or instead of the annotation? Making it explicit what users or hosts can authenticate using this authenticator?
Will authn stay enabled as today? why not provide it the same UX as any other authenticators?

rafis3 commented 4 years ago

Regarding the UX of this feature, I wanted to propose that this indication would be in an annotation, like any other authentication we support. Something that would look like this:

- !host
  id: myhost
  annotations:
    authn/api-key: false

cyberark / conjur