OpenStack Keystone Single Sign-On (SSO) Setup

In an earlier blog, we discussed how to setup Federated Identity for Openstack Keystone so that a Service Provider (SP) Keystone instance can hand off authentication to an external service, called the Identity Provider (IdP). One of the benefits with this is to enable OpenStack Keystone Single Sign-On (SSO), via APIs or Horizon dashboard, so that a single login can provide access to multiple services. This blog will give an overview of how to setup KeyStone Single Sign-on for Web access.

How websso login with Keystone works

OpenStack Keystone Single Sign-On (SSO) Setup

Credit: http://wikipedia.org

  1. Initial request for a resource e.g. a Nova API
  2. This begins a redirect to a specific IdP based on the protocol
  3. The browser displays the IdP’s login form. When the user enters credentials, the browser POSTs credentials to IdP.
  4. On success, the IdP returns a XHMTL form with a SAML token
  5. The browser then post the SAML assertion to the SAML endpoint in Shibboleth on the Keystone server.
  6. Shibboleth responds with a redirect back to the original auth URL.
  7. Shibboleth redirects back to Keystone, this time with a Shibboleth cookie, and request the target resource again
  8. Since the user is now authenticated, Keystone will issue JavaScript code that redirects the web browser to the originating Horizon. An unscoped federated token will be included in the form being sent. The unscoped token can now be scoped and then used to call OpenStack APis

The configuration files for both OpenStack Keystone and Horizon need to be updated to enable SSO. The detailed steps are listed below. As a prerequisite, Keystone must be run under Apache by following the steps available here

Updates to Keystone Configuration

  • Update trusted_dashboard in keystone.conf file
    This value will specify one or more URLs of trusted OpenStack Horizon servers. This ensures that Keystone communicates token data back with trusted servers only, to prevent man-in-the-middle (MITM) attacks.
    [code lang=”bash”][federation] trusted_dashboard = http://abc.horizon.com/auth/websso/
    trusted_dashboard = http://def.horizon.com/auth/websso/[/code]
  • Update httpd vhost file with websso information.
    The paths /v3/auth/OS-FEDERATION/websso/ and /v3/auth/OS-FEDERATION/identity_providers/{idp_id}/protocols/{protocol_id}/websso must be access protected. This is performed so the request that originates from Horizon will use the same Identity Provider that is configured in keystone.

For Shibboleth plugin, mod_shib, the following changes are required
[code lang=”xml”] …

AuthType shibboleth
Require valid-user

AuthType shibboleth
Require valid-user

[/code]
  • Update remote_id_attribute in keystone.conf
    The remote_id_attribute indicates the header that contains information about the IdP. For mod_shib this would be Shib-Identity-Provider
[code lang=”bash”][saml2] remote_id_attribute = Shib-Identity-Provider[/code]
  • Set remote_ids for a keystone identity provider
    A keystone identity provider may have multiple remote_ids specified so that the same identity provider resource may be used for multiple external identity providers. This removes the need to configure N identity providers in Keystone. For example, when Keystone has to be connected with a federation having multiple IdPs, and all share the same set of attributes and policies, then a single map can manage all IdPs in the SP Keystone.
    [code lang=”bash”]$ openstack identity provider set –remote-id [/code]

Updates to OpenStack Horizon Configuration

In the configuration file local_settings.py

  • Set the Identity Service version
    [code lang=”bash”]OPENSTACK_API_VERSIONS = { “identity”: 3 }[/code]
  • Authenticate against Identity Server v3
    [code lang=”bash”]OPENSTACK_KEYSTONE_URL = “http://keystone_ip:5000/v3″[/code]
  • Set the WEBSSO_ENABLED option to True to provide users with a updated login screen
    [code lang=”bash”]WEBSSO_ENABLED = True[/code]

The updates below for the local_setting.py file are optional based on specific requirements

  • Create a list of authentication methods

The list includes Keystone federation protocols such as OpenID Connect and SAML, and also keys that map to specific identity provider and federation protocol combinations
[code lang=”xml”]WEBSSO_CHOICES = (
(“credentials”, _(“Keystone Credentials”)),
(“oidc”, _(“OpenID Connect”)),
(“saml2”, _(“Security Assertion Markup Language”)),
(“idp_1_oidc”, “ABC Corporation – OpenID Connect”),
(“idp_1_saml2”, “DEF Corporation – SAML2”)
)[/code]

  • Create a dictionary of specific identity provider and federation protocol combinations.

For the selected authentication mechanism, the user will be redirected to a identity provider and federation protocol specific WebSSO endpoint
[code lang=”xml”]WEBSSO_IDP_MAPPING = {
“idp_1_oidc”: (“idp_1”, “oidc”),
“idp_1_saml2”: (“idp_1”, “saml2”)
}[/code]

  • Specify an initial choice

The list set by the WEBSSO_CHOICES option will be generated in a drop-down menu in the login screen and the initial choice set below will be highlighted by default.
[code lang=”xml”]WEBSSO_INITIAL_CHOICE = “credentials”[/code]

  • Finally, stop the keystone service and restart apache.

This will complete the required setup and the SSO options will now be displayed on the login page of Horizon’s UI.

If the enterprise single sign-on requirements are to configure authentication with directory services such as LDAP, AD or ADFS, then these other blogs may be useful
Keystone Authentication using LDAP
Keystone Authentication using AD
Keystone Authentication using ADFS
Keystone Federation Setup

Platform9

You may also enjoy

VMware vs OpenStack: Why OpenStack is the better VMware alternative in 2024

By Kamesh Pemmaraju

Maximize cloud usage and cost efficiency using FinOps best practices

By Kamesh Pemmaraju

The browser you are using is outdated. For the best experience please download or update your browser to one of the following:

Leaving VMware? Get the VMware alternatives guideDownload now