Using OAuth and/or OpenID Connect for Federated Access to OpenStack/Keystone

This blueprint shows how the OAuth and/or OpenID Connect protocols can be used to authenticate to Keystone using the same protocol flow as in the existing Federation blueprint

http://wiki.openstack.org/Keystone/Federation/Blueprint

The current implementation of Federated Access to OpenStack uses the SAMLv2 protocol. However the federated design is meant to be protocol independent. In order to verify this point, we should be able to use other protocols such as OAuth or OpenID Connect to access Keystone instead of SAML. OAuth and OpenID Connect use a completely different protocol exchange to that of SAML. The OAuth exchange, as implemented by ForgeRock in its open source software, can seen here:

https://wikis.forgerock.org/confluence/display/openam/OpenAM+OAuth+Implementation

In order to integrate a different protocol into Keystone, we need to specify how the Request Issuing Service (RIS) and Credential Validation Service (CVS) of Federated Keystone will work, without changing the existing protocol flow as implemented by the various OpenStack clients.

Referring to the ForgeRock diagram, the Consumer is Keystone. The Service Provider is the user’s Identity Provider, and the User is the OpenStack client software. Using the numbering system from ForgeRock’s Fetching the Request Token diagram, we have:
1. The client contacts Keystone for federated access as now
a. Keystone contacts the service catalog to find out what IdPs are available and returns the list to the user (as now).
b. The user/client chooses the OAuth IdP he wants to use.
c. The RIS fetches the IdP’s meta data from the service catalog and sees that it supports the OAuth protocol (the service type is IDP.OAuth)
2. The RIS contacts the IdP to Obtain a Request Token
3. The Request Token is returned to the client in a redirect message to the IdP (Service Provider) (as now)

Continuing at ForgeRock’s Authenticating to Service Provider diagram:
1. The client forwards the Request Token to the IdP, via the user’s browser (as now)
a. The user authenticates to the IdP giving his username and password
2. The user authorises Keystone to have access to his identity attributes
3. The IdP redirects the client back to Keystone
a. The client software traps the request in Local Host, picks up the message and sends it to Keystone

Continuing at ForgeRock’s Obtaining the Access Token diagram:
1. The client sends the message to Keystone
2. The CVS receives the message and passes it the IdP for validation. We could perhaps make the “return to” address different for OAuth and SAML so that the CVS does not need to parse the message to tell the difference between a SAML response and an OAuth response, but instead can tell from the URL.
3. The IdP validates the message it has received from the Keystone CVS and passes back the Access Token.
4. The CVS uses the access token to request the user’s attributes from the IdP.
5. The CVS then calls the Attribute Mapper to get the user’s tenant and Roles and continues as before.