OpenStack Keystone Documentation

Keystone is the OpenStack service responsible for providing API client authentication, service discovery, and distributed multi-tenant authorization. It implements the OpenStack Identity API.

Developers can interact with Keystone through several related components:

• WSGI middleware: For integrating Keystone authentication into WSGI applications.
• Authentication library: For handling authentication logic.
• Python client library: For programmatic access to Keystone services.

Keystone provides two primary ways to interact with its services:

1. python-keystoneclient: Provides Python bindings for programmatic access.
2. python-openstackclient: Provides a command-line interface (CLI) for managing Keystone resources.

The keystone-manage command-line tool is used to interact with the Keystone service for administrative operations that cannot be performed via the standard HTTP API. Its primary use cases include:

• Database Migrations: Updating the Keystone database schema.
• Data Import/Export: Moving Keystone data between environments.
• Initialization: Setting up the initial Keystone data structures.

Usage Pattern:

keystone-manage [options] action [additional args]

Keystone Federation allows sharing identity information across multiple identity management systems. Instead of Keystone managing user credentials directly, users authenticate with an external identity source, which then provides Keystone with user attributes.

This is distinct from using LDAP as an identity backend; while LDAP allows Keystone to fetch identity information, Keystone still handles the passwords directly. In Federation, authentication is offloaded to the external source.

Key use cases include:

• Using an existing primary identity source so users don't need new cloud credentials.
• Connecting multiple clouds by using one Keystone instance as an identity source for another.

X.509 Tokenless Authorization allows Keystone to authorize client operations using an X.509 SSL client certificate instead of requiring the issuance and validation of a user token.

This approach provides several benefits:

• Reduced Complexity: Eliminates the need for auth_token middleware to use a service user token for authentication and authorization.
• Operational Efficiency: Avoids the overhead of requesting, caching, and renewing service user tokens.
• Improved Security: Uses X.509 certificates for authentication instead of passwords, and removes the need to manage and protect service user credentials in configuration files.

The Flat enforcement model treats every project as an isolated peer, completely ignoring any project hierarchy.

Key Characteristics:

• Isolation: Limits and usage in parent, sibling, or child projects have no effect on a specific project.
• Validation: You can set a child project's limit higher than its parent's limit.
• Manual Control: To simulate hierarchy, you must manually adjust limits through the project tree.

When to use it:

• When your project hierarchies are deeper than two levels.
• When you require extremely strict isolation and do not want resource usage to bleed across projects or domains.

You can extract values from IdP attributes using the empty condition and substitute them into local user attributes using indexed placeholders {0}, {1}, etc. The indices correspond to the order of the remote attribute list.

Example: If your remote attributes are [{"type": "FirstName"}, {"type": "LastName"}], then {0} maps to the FirstName value and {1} maps to the LastName value.

{
       "rules": [
           {
               "local": [
                   {
                       "user": {
                           "name": "{0} {1}"
                       }
                   }
               ],
               "remote": [
                   { "type": "FirstName" },
                   { "type": "LastName" }
               ]
           }
       ]
   }

In Keystone-to-Keystone federation, an attribute file (such as a Shibboleth attribute-map.xml) is used to add attributes to the mapping context. The Service Provider (SP) matches these attributes against the remote section of the mapping rules.

Available attributes for mapping include:

• openstack_user
• openstack_user_domain
• openstack_roles
• openstack_project
• openstack_project_domain
• openstack_groups