Client SSL certificate authorization

For obvious reasons, most security policies dictate Keystone to be deployed with either one-way SSL (with server authentication) or two-way SSL (mutual authentication). In the case of two-way SSL, the client certificate can be used for both authentication and authorization. Today, Keystone authorization is facilitated by OSLO policy engine. A typical API authorization flow goes like this.

1. client authenticate to Keystone using one or more supported authentication methods (i.e. password)
2. Keystone validates client credential and issue a token
3. client invokes a Keystone API (i.e. GET /v3/users) using the token by setting it in the X-Auth-Token header
4. Keystone validates the client token and converts it into an authentication context (auth context)
5. Keystone performs authorization by matching the auth context against the target resource (i.e. user_ref). This is done by using OSLO policy engine. If a match is made, client is authorized to perform the operation.

With two-way SSL, we can simplify this process by directly converting the client SSL certificate into an auth context. Therefore, eliminating the need for having to maintain and issue a client token. This approach offer two major benefits: reduced complexity and performance improvement. Not to mention other security benefits with two-way SSL as it has already offered us implicit token binding and therefore achieving the non-bearer tokens objective. With the proposed approach, the new API authorization flow goes like this.

1. client invoke a Keystone API by establishing a two way SSL session
2. Keystone validates the client SSL certificate and translates it into an auth_context using the information from the subject distinguished name (DN).
3. Keystone performs authorization by matching the auth context against the target resource (i.e. user_ref). This is done by using OSLO policy engine. If a match is made, client is authorized to perform the operation.

Note that this approach may only work if Keystone is front-ended by a third party Web Server such as Apache because native Paste Deploy and Eventlet do not set the client SSL certificate information in the request environment.