Bug 1041893 - [RFE][keystone]: Encrypt OAuth access keys
Summary: [RFE][keystone]: Encrypt OAuth access keys
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: RFEs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Maint
QA Contact:
URL: https://blueprints.launchpad.net/keys...
Whiteboard: upstream_milestone_none upstream_stat...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-12 19:56 UTC by RHOS Integration
Modified: 2015-03-19 17:26 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-19 17:26:28 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description RHOS Integration 2013-12-12 19:56:00 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/keystone/+spec/oauth1-encrypted-access-keys.

Description:

Similar to the PKI tokens issued by keystone, encrypted OAuth access keys can contain enough information to allow offline:

- oauth-based request integrity validation
- openstack authorization data (tenancy & roles)

In pseudo code, to generate an access key:

    access_key = encrypt(secret_key + project_id + role_ids)

Given an oauth-signed request, an OpenStack service remote to keystone may verify an oauth-signed request by decrypting the access key provided by the client in plaintext:

    secret_key, project_id, role_ids = decrypt(access_key)

For a demo implementation, see:

  https://gist.github.com/dolph/6198529

Considerations:

- If the secret key is recoverable from the access key by a third party, then auth, request integrity, etc, is completely broken
- Access keys may be used in URL's (e.g. keystone's OS-OAUTH1 extension API), so length and encoding of the generated keys may impact compatibility

Specification URL (additional information):

None


Note You need to log in before you can comment on or make changes to this bug.