OpenStack Identity (Keystone)

Access Key Authentication

Registered by Guang Yee on 2012-03-19

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:
Not started
Approver:
None
Priority:
Medium
Drafter:
Guang Yee
Direction:
Needs approval
Assignee:
Fabio Giannetti
Definition:
Discussion
Series goal:
None
Implementation:
Not started
Milestone target:
None

Related branches

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-comprehansiveable passwords.

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": {
            methods": [
                "access-key"
           ],
           "access-key": {
             "access":"VCAVE3Y6RL9K8ADVKMY5",
                  "secret":"quyNVz7gMtpG9QsLz0DUrqGocYbr5X+KGbkJsqzs"
           }
        }
    }
}

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://bugs.launchpad.net/tempest/+bug/1005968

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.