Support tokenless authorization with X.509 client SSL certificate to improve security and simplify deployment.
See X.509 for more information on X.509 certificates.
In a typical enterprise deployment, SSL client certificate authentication is required for services talking to Keystone for things such as token validation and resource lookup. For example, we configure a client certificate for the auth_token middleware running at the service to establish the SSL client certificate authentication session with Keystone when validating a user token. In this case, there’s no need for the service to take the extra unnecessary step to obtain a service token in order to authorize the token validation call. We can effectively identify the service by its X.509 SSL client certificate. With the X.509 SSL client certificate attributes, coupled with the scope information conveyed in the request headers, we can directly create the authorization credential by looking up the necessary identity data without having to issue a token. The authorization credential is successfully created if all of the following conditions are true:
The benefits of tokenless authorization with X.509 SSL client certificate are:
This is accomplished by implementing a middleware filter which builds the authorization credential based on the certificate attributes and scope information from the request headers. Authorization credential is a Python dictionary which represents the credential used in Oslo policy enforcement.
Since we are using Apache mod_ssl to handle the SSL requests, Apache will convey the client certificate information in the WSGI request environment. For example:
SSL_CLIENT_S_DN SSL_CLIENT_S_DN_CN SSL_CLIENT_S_DN_O SSL_CLIENT_S_DN_OU SSL_CLIENT_I_DN
See http://httpd.apache.org/docs/current/mod/mod_ssl.html for more details.
This middleware shall use the mapping functionality, implemented for Federation, to formulate the Keystone identity from the SSL environment variables. Each issuer (i.e. certification authority) would constitute an identity provider (IdP). There would be exactly one mapping per IdP. The IdP ID would be the SHA256 hash of the issuer DN.
In addition, this middleware shall accept the following configurable option, defined in [auth] configration section in keystone.conf, to further filter the certificates that are allowed to participate in tokenless authorization:
trusted_issuers = [<list of trust issuer DNs>]
If trusted_issuers is absent, no certificates will be allowed in tokenless authorization.
Furthermore, this middleware shall expect the following request headers to convey the scope information:
HTTP_X_PROJECT_ID HTTP_X_PROJECT_NAME HTTP_X_PROJECT_DOMAIN_ID HTTP_X_PROJECT_DOMAIN_NAME HTTP_X_DOMAIN_ID HTTP_X_DOMAIN_NAME
Absence of the scope headers is equivalent to an unscoped token. Notice that only one scope can be specified for a given request. For example, if both project and domain scope are specified, that would constitute an error.
Use the existing mechanism, which is to use the service token for authorization.
This mechanism has the effect of non-bearer token as the SSL client must possess the corresponding private key for its SSL certificate.
In order to use this functionality, service must have a valid X.509 client SSL certificate. However, certificate management is outside the scope of this spec.
This feature only works in conjunction with Apache mod_ssl or mod_nss as standalone eventlet-based Keystone does not parse or convey X.509 client SSL certificate attributes in the request environment. Therefore, Keystone must be running in Apache mod_wsgi.
Notice that if the deployment terminates SSL in a load balancer, then the load balancer must be configured to forward the SSL client certificate.
In order for Apache mod_ssl to convey the SSL client certificate information in the request environment, the SSLOptions directive must contains +StdEnvVars and the SSLUserName directive must be set to a valid SSL requirement environment attribute.
SetEnv AUTH_TYPE SSL SSLOptions +StdEnvVars SSLUserName SSL_CLIENT_S_DN_CN
SSLUserName directive must not be used with +FakeBasicAuth option. For more details, please refer to Apache mod_ssl Also, notice the environment variable AUTH_MECHANISM, this is used to determine which mapping to use in case we support other protocols in the future.
This feature only works in conjunction with Apache mod_ssl or mod_nss. Therefore, Keystone must be running in Apache mod_wsgi.
There will be unit tests. For integration tests, we may need both X.509 certificate management capability (i.e. Barbican + DogTag) and Apache enabled in Jenkins.
Enter search terms or a module, class or function name.