Keystone Federation

Keystone can be configured to integrate with a number of different identity providers in a number of different configurations. This spec attempts to discuss how to implement pluggable backends that utilise Keystone federations.

Problem Description

When deploying the OpenStack charms to an enterprise customer they are likely to want to integrate OpenStack authentication with an existing identity provider like AD, LDAP, Kerberos etc. There are two main ways that Keystone appears to achieve this integration: backends and federation. Although this spec is concerned with federation it is useful to go over backends to in an attempt to distinguish the two.

The following are not covered here:

  • Integration with Kerberos

  • Horizon SSO

  • Federated LDAP via SSSD and mod_lookup_identity

  • Keystone acting as an IdP in a federated environment.

Backends

When keystone uses a backend it is Keystone itself which knows how to manage that backend, how to talk to it and how to deal with operations on it. This limits the number of backends that keystone can support as each new backend needs new logic in Keystone itself. This approach also has negative security implications. Keystone may need an account with the backend (an LDAP username and password) to perform lookups, these account details will be in clear text in the keystone.conf. In addition, all users passwords with flow through keystone.

The keystone project highlights SQL and LDAP (inc AD) as their supported backends. The status of support for these is as follows:

  • SQL: Currently supported by the keystone charm.

  • LDAP: Currently supported by the keystone and keystone-ldap subordinate.

These backends are supported with the Keystone v2 API if they are used exclusively. To support multiple backends then Keystone v3 API needs to be used and each backend is associated with a particular Keystone domain. This allows for service users to be in SQL but users to be in ldap for example.

Adding a new backend is achieved by writing a keystone subordinate charm and relating it to keystone via the keystone-domain-backend interface.

Enabling a backend tends to be achieved via the keystone.conf

Federation

With federation Keystone trusts a remote Identity provider. Keystone communicates with that provider using a protocol like SAML or OpenID connect. Keystone relies on a local Apache to manage communication and Apache passes back to keystone environment variables like REMOTE_USER. Keystone is abstracted from the implementation details of talking to the identity provider and never sees the users password. When using Federation, LDAP may still be the ultimate backend but it is fronted by something providing SAML/OpenID connectivity like AD federation service or Shibboleth.

Each Identity provider must be associated with a different domain within keystone. The keystone v3 API is needed to support federation.

Compatible Identity Providers: (https://docs.openstack.org/ocata/config-reference/identity/federated-identity.html#supporting-keystone-as-a-sp ):

  • OpenID

  • SAML

Proposed Change

Both Keystone backends and federated backends may need to add config to the keystone.conf and/or the Apache WSGI vhost. As such, it makes sense for both types to share the existing interface particularly as the existing interface is called keystone-domain-backend which does not differentiate between the two.

This spec covers changes add support for federation using either SAML or OpenID, to the keystone charm. This will involve extending the keystone-domain-backend interface to support passing configuration snippets to the Apache vhosts and creating subordinate charms which implement OpenID and SAML.

Alternatives

  • Add support for federation via OpenID and SAML directly to the keystone charm.

  • Create a new interface for federation via OpenID and SAML

Implementation

Assignee(s)

Primary assignee:

None

Gerrit Topic

Use Gerrit topic “keystone_federation” for all patches related to this spec.

git-review -t <keystone_federation>

Work Items

Create deployment scripts to create test env for OpenID or SAML integration

Extend keystone-domain-backend

The keystone-domain-backend interface will need to provide the following:

  • Modules for Apache to enable

  • Configuration for principle to insert into Apache keystone wsgi vhosts

  • Subordinate triggered restart of Apache

  • Auth method(s) to be added to keystone’s [auth] methods list

  • Configuration for principle to insert into keystone.conf

Configure Keystone to consume new interface

Keystone charm will need to be updated to respond to events outlined in the interface description above

New keystone-openid and keystone-saml subordinates

The new subordinates will need to expose all the configuration options needed for connecting to the identity provider. It will then need to use the interface to pass any required config for Apache or Keystone up to the keystone principle.

Repositories

New projects for the interface and new subordinates will be needed.

Documentation

This will require documentation in the READMEs of both the subordinates and the keystone charm. A blog walking through the deployment and integration would be very useful.

Security

Although a Keystone back-end will determine who has access to the entire OpenStack deployment, this specific charm will only change Keystone and Apache parameters, avoiding default values and leave the configuration to the user should be enough.

Testing

The code must be covered by unit tests. Ideally amulet tests would be extended to cover this new functionality but deploying a functional openid server for keystone to use may not be practical. It must be covered by a Mojo spec though.

Dependencies

None