Using external authentication with Keystone¶

Configuration¶

In Identity API v2, there is no way to disable external authentication. In order to activate the external authentication mechanism for Identity API v3, the external method must be in the list of enabled authentication methods. By default it is enabled, so if you don’t want to use external authentication, remove it from the methods option in the auth section.

To configure the plugin that should be used set the external option again in the auth section. There are two external authentication method plugins provided by Keystone:

• DefaultDomain: This plugin won’t take into account the domain information that the external authentication method may pass down to Keystone and will always use the configured default domain. The REMOTE_USER variable is the username. This is the default if no plugin is given.
• Domain: This plugin expects that the REMOTE_DOMAIN variable contains the domain for the user. If this variable is not present, the configured default domain will be used. The REMOTE_USER variable is the username.

methods = external,password,token,oauth1

Using HTTPD authentication¶

Web servers like Apache HTTP support many methods of authentication. Keystone can profit from this feature and let the authentication be done in the web server, that will pass down the authenticated user to Keystone using the REMOTE_USER environment variable. This user must exist in advance in the identity backend to get a token from the controller.

To use this method, Keystone should be running on HTTPD.

<VirtualHost _default_:5000>
    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/ssl.cert
    SSLCertificateKeyFile /etc/ssl/private/ssl.key

    SSLCACertificatePath /etc/ssl/allowed_cas
    SSLCARevocationPath  /etc/ssl/allowed_cas
    SSLUserName          SSL_CLIENT_S_DN_CN
    SSLVerifyClient      require
    SSLVerifyDepth       10

    (...)
</VirtualHost>

Developing a WSGI middleware for authentication¶

In addition to the method described above, it is possible to implement other custom authentication mechanisms using the REMOTE_USER WSGI environment variable.

If you find you must implement a custom authentication mechanism, you will need to develop a custom WSGI middleware pipeline component. This middleware should set the environment variable REMOTE_USER to the authenticated username. Keystone then will assume that the user has been already authenticated upstream and will not try to authenticate it. However, as with HTTPD authentication, the user must exist in advance in the identity backend so that a proper token can be issued.

Your code should set the REMOTE_USER if the user is properly authenticated, following the semantics below:

from keystone.common import wsgi
from keystone import exception

class MyMiddlewareAuth(wsgi.Middleware):
    def __init__(self, *args, **kwargs):
        super(MyMiddlewareAuth, self).__init__(*args, **kwargs)

    def process_request(self, request):
        if request.environ.get('REMOTE_USER', None) is not None:
            # Assume that it is authenticated upstream
            return self.application

        if not self.is_auth_applicable(request):
            # Not applicable
            return self.application

        username = self.do_auth(request)
        if username is not None:
            # User is authenticated
            request.environ['REMOTE_USER'] = username
        else:
            # User is not authenticated, render exception
            raise exception.Unauthorized("Invalid user")

[filter:my_auth]
paste.filter_factory = keystone.middleware.MyMiddlewareAuth.factory

[pipeline:public_api]
pipeline = url_normalize token_auth admin_token_auth json_body debug ec2_extension user_crud_extension public_service

[pipeline:public_api]
pipeline = url_normalize token_auth admin_token_auth json_body my_auth debug ec2_extension user_crud_extension public_service