Configuring Keystone for Tokenless Authorization¶

Prerequisites¶

Keystone must be running in a web container with https enabled; tests have been done with Apache/2.4.7 running on Ubuntu 14.04 . Please refer to running-keystone-in-httpd and apache-certificate-and-key-installation as references for this setup.

Create an Identity Provider (IdP)¶

In order to create an IdP, the issuer DN in the client certificate needs to be provided. The following sample is what a generic issuer DN looks like in a certificate.

E=john@openstack.com
CN=john
OU=keystone
O=openstack
L=Sunnyvale
S=California
C=US

The issuer DN should be constructed as a string that contains no spaces and have the right order separated by commas like the example below. Please be aware that emailAddress and ST should be used instead of E and S that are shown in the above example. The following is the sample Python code used to create the IdP ID.

import hashlib
issuer_dn = 'emailAddress=john@openstack.com,CN=john,OU=keystone,
    O=openstack,L=Sunnyvale,ST=California,C=US'
hashed_idp = hashlib.sha256(issuer_dn)
idp_id = hashed_idp.hexdigest()
print(idp_id)

The output of the above Python code will be the IdP ID and the following sample curl command should be sent to keystone to create an IdP with the newly generated IdP ID.

curl -k -s -X PUT -H "X-Auth-Token: <TOKEN>" \
     -H "Content-Type: application/json" \
     -d '{"identity_provider": {"description": "Stores keystone IDP identities.","enabled": true}}' \
     https://<HOSTNAME>:<PORT>/v3/OS-FEDERATION/identity_providers/<IdP ID>

Create a Map¶

A mapping needs to be created to map the Subject DN in the client certificate as a user to yield a valid local user if the user’s type defined as local in the mapping. For example, the client certificate has Subject DN as CN=alex,OU=eng,O=nice-network,L=Sunnyvale, ST=California,C=US, in the following examples, user_name will be mapped to“alex“ and domain_name will be mapped to nice-network. And it has user’s type set to local. If user’s type is not defined, it defaults to ephemeral.

Please refer to mod_ssl for the detailed mapping attributes.

{
     "mapping": {
         "rules": [
             {
                 "local": [
                     {
                        "user": {
                            "name": "{0}",
                            "domain": {
                                "name": "{1}"
                            },
                            "type": "local"
                        }
                     }
                ],
                "remote": [
                    {
                        "type": "SSL_CLIENT_S_DN_CN"
                    },
                    {
                        "type": "SSL_CLIENT_S_DN_O"
                    }
                ]
            }
        ]
    }
}

When user’s type is not defined or set to ephemeral, the mapped user does not have to be a valid local user but the mapping must yield at least one valid local group. For example:

{
     "mapping": {
         "rules": [
             {
                 "local": [
                     {
                        "user": {
                            "name": "{0}",
                            "type": "ephemeral"
                        }
                     },
                     {
                        "group": {
                            "id": "12345678"
                        }
                     }
                ],
                "remote": [
                    {
                        "type": "SSL_CLIENT_S_DN_CN"
                    }
                ]
            }
        ]
    }
}

The following sample curl command should be sent to keystone to create a mapping with the provided mapping ID. The mapping ID is user designed and it can be any string as opposed to IdP ID.

curl -k -s -H "X-Auth-Token: <TOKEN>" \
     -H "Content-Type: application/json" \
     -d '{"mapping": {"rules": [{"local": [{"user": {"name": "{0}","type": "ephemeral"}},{"group": {"id": "<GROUPID>"}}],"remote": [{"type": "SSL_CLIENT_S_DN_CN"}]}]}}' \
     -X PUT https://<HOSTNAME>:<PORT>/v3/OS-FEDERATION/mappings/<MAPPING ID>

Create a Protocol¶

The name of the protocol will be the one defined in keystone.conf as protocol which defaults to x509. The protocol name is user designed and it can be any name as opposed to IdP ID.

A protocol name and an IdP ID will uniquely identify a mapping.

The following sample curl command should be sent to keystone to create a protocol with the provided protocol name that is defined in keystone.conf.

curl -k -s -H "X-Auth-Token: <TOKEN>" \
     -H "Content-Type: application/json" \
     -d '{"protocol": {"mapping_id": "<MAPPING ID>"}}' \
     -X PUT https://<HOSTNAME>:<PORT>/v3/OS-FEDERATION/identity_providers/<IdP ID>/protocols/<PROTOCOL NAME>

Configurable Options¶

The following configurable options in auth_token middleware should set to the correct values:

• auth_protocol - Set to https.
• certfile - Set to the full path of the certificate file.
• keyfile - Set to the full path of the private key file.
• cafile - Set to the full path of the trusted CA certificate file.

Scope Information¶

The scope information will be passed from the headers with the following header attributes to:

• X-Project-Id - If specified, its the project scope.
• X-Project-Name - If specified, its the project scope.
• X-Project-Domain-Id - If specified, its the domain of project scope.
• X-Project-Domain-Name - If specified, its the domain of project scope.
• X-Domain-Id - If specified, its the domain scope.
• X-Domain-Name - If specified, its the domain scope.

Details of the Options¶

• --cert - The client certificate that will be presented to Keystone. The Issuer in the certificate along with the defined protocol in keystone.conf will uniquely identify the mapping. The Subject in the certificate will be mapped to the valid local user from the identified mapping.
• --key - The corresponding client private key.
• --cacert - It can be the Apache server certificate or its issuer (signer) certificate.
• X-Project-Name - The project scope needs to be passed in the header.
• X-Project-Domain-Id - Its the domain of project scope.
• X-Subject-Token - The token to be validated.