Delegated Auth a la Oauth

Registered by termie

A method by which for to be producing the providance of the ability to request tokens with a limited scope in the case of a third party

Spec available at: https://review.openstack.org/#/c/36613/
Use case at: https://gist.github.com/termie/5225817

Blueprint information

Status:
Complete
Approver:
Dolph Mathews
Priority:
Medium
Drafter:
termie
Direction:
Approved
Assignee:
Steve Martinelli
Definition:
Approved
Series goal:
Accepted for havana
Implementation:
Implemented
Milestone target:
milestone icon 2013.2
Started by
Dolph Mathews
Completed by
Dolph Mathews

Related branches

Sprints

Whiteboard

For use case / flow, see this etherpad: https://etherpad.openstack.org/oauth

Gerrit topic: https://review.openstack.org/#q,topic:bp/delegated-auth-via-oauth,n,z

Addressed by: https://review.openstack.org/29130
    Add delegated_auth support for keystone
Addressed by: https://review.openstack.org/#/c/30043/
    Add OAuth support for keystoneclient

Typical OAuth Flow:

$ openstack oauth consumer create stevemar
{
    consumer_key : 123,
    consumer_secret : 123-secret,
    domain_id : default,
    id: 123-secret,
    name: stevemar
}

$ openstack oauth request token create --roles admin --consumer-key 123 --consumer-secret 123-secret
{
    request_token_key : 456, request_token_secret : 456-secret
}

$ openstack oauth request token authorize --roles role_1--request-key 456
{
    oauth_verifier : 2826
}

$ openstack oauth access token create --consumer-key 123 --consumer-secret 123-secret --request-key 456 --request-secret 456-secret --verifier 2826
{
    access_token_key : 789,
    access_token_secret : 789
}

$ openstack oauth access token authenticate --consumer-key 123 --consumer-secret 123-secret --access-key 789 --access-secret 789-secret
{
    expire: 2013-06-12T19:26:10.577000
    id :9k04l4
    project_id : 8a8a8a
    user_id : 7f7b7f7
}

At this point, the consumer now has a keystone token with access to roles that were requested. The keystone token will expire in the default number of days, at which point the consumer will have to get a new keystone token.

From an administrator point of view, the admin can remove access from the access token. Examples below for listing user authorizations and removing an authorization.
$ openstack oauth authorization list --user-id 7f7b7f7
[{
    issued_at: 2013-06-12T19:26:10.577000
    access_key: 789
    consumer_key :123
    requested_roles: [role_1]
    project_id : 8a8a8a
    user_id : 7f7b7f7
}]

$ openstack authorization delete --user-id 7f7b7f7--access-key 789
*deletes from the table above, deletes any generated request + access + keystone tokens too

(?)

Work Items

Work items:
create_request_token: DONE
create_access_token: DONE
authorize_token: DONE
backend kvs for above mentioned functions: DONE
backend kvs for consumer CRUD: DONE
unittests for consumer CRUD: DONE
unittests for OAuthFlow (up to using access token): DONE
list user authorizations: DONE
delete user authorization: DONE
keystone token generation (Authenticate in core): DONE
get authorization pin: DONE
sql backend: DONE