Access Key Authentication
We would like to add a generic access key authentication capability to the Keystone service API. There used to be an RAX-KSKEY extension which addresses a specific use case. But we would like expose a more generic interface so we can support all key based authentications. This feature adds both security and usability to the existing Keystone authentication functionality.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Not
- Drafter:
- Guang Yee
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
- Morgan Fainberg
Related branches
Related bugs
Sprints
Whiteboard
Motivation
We would like to add a generic access key authentication capability to the Keystone service API. There used to be an RAX-KSKEY extension which addresses a specific use case. But we would like expose a more generic interface so we can support all key based authentications.
This feature adds both security and usability to the existing Keystone authentication functionality.
Security
Arguably, key based authentication is more secure than standard password authentication because keys are more resistant to dictionary or brute force attack if done right. Keys, private or secret, are usually randomly generated much longer than human-comprehan
Usability
We are already using key based authentication on daily basis. i.e. SSH keys, EC2 keys, etc. Users should be able to use their own keys to authenticate to mutiple systems. Think SSO.
Take Nova client operations for example, we no longer need two sets of credentials. We can just use access key authentication for both Nova client and EC2 operations. Much easier to comprehand than using one set of credential for Nova client and different set of credentials for euca2ools.
API Changes
In addition to service API for authentication, we will also need to expose admin APIs to enable users to perform key management. The usual CRUD operations: import key, update key, delete key, and list key.
Service API Changes
POST /v3/auth/tokens
Here's a sample request:
{
"auth":{
"identity": {
],
}
}
}
}
Where "access" is the key identifier, and "secret" is the key itself.
The response would be a valid token response upon successful authentication, no different from a password authentication response. Needless to say, clients will need to be updated in order to support the new API.
Test Scenarios:
https:/
This should integrate with the current Credentials backend, and not be a separate implementation.
Can this be superseded by the password rotation mechanism? (if that's not blueprinted, I'd be happy to create one) -dolph
Work Items
Work items:
[fabio-giannetti] Define interface with Credentials Backend: TODO
Dependency tree
* Blueprints in grey have been implemented.
