Provide the ability for a user to authenticate via a web browser with an existing IdP, through a Single Sign-On page. Keystone should be able to create a token and post it back to a requestor to support Federation protocols.
Since this is a cross-project spec, the blueprint for horizon is: bp federated-identity
With password based authentication, Horizon has been responsible for carrying the shared secret between the user and Keystone. Cryptographically secure authentication mechanisms protect against this, as it leads to various Man-in-the-middle attack scenarios. If the Horizon server is compromised, it would grant the attacker access to the password for all users that log in. When coupled with a corporate directory, this poses a significant risk.
The proper sequence is * Horizon redirects the browser to Keystone * Keystone redirects to Discovery Service or default IdP * The User authenticates via an IdP specific mechanism * The IdP redirects the browser back to Keystone * Keystone generates Javascript code to POST a token back to Horizon * Keystone redirects the user to Horizon.
The Keystone server needs to enable the redirect to the IdP, and accept back the SAML assertion in order to create the token.
Horizon would implement a way to choose preferred authentication method. Technically, a user would be redirected to different route at the Keystone server. Keystone will implement additional routes/endpoints that allow for different forms of login. Initially these will be:
For SAML and OpenID Connect, the Horizon (or compatible WebUI) will redirect to the appropriate protected Keystone URL (depending on the implementation, /v3/OS-FEDERATION/websso/{protocol}?origin=https%3A//horizon.example.com or /v3/auth/websso/{protocol}?origin=https%3A//horizon.example.com).
It’s important to mention that {protocol} variables must be registered (and tied to identity provider object issuing assertions) via the OS-FEDERATION API.
The algorithm for identifying mapping to be used:
1) Fetch attribute storing identity provider identifier.
2) Fetch identity_provider basing on the previous value (return error
code if no such identity_provider was found).
3) Fetch protocol value from the URL (return error if no such
protocol was found tied to such identity_provider).
4) Fetch mapping id identified by identity_provider and protocol
ids.
JavaScript that performs a HTTP POST to the original webUI. The URL that Keystone will POST user back will be stored in the initial URL.
Note, that Horizon will not accept POST requests, so the function that handles this portion would need to be exempt from CSRF errors.
The proposed work flow is depicted on an ASCII diagram below.
+----------------+ +----------------+ +----------------+
| | | | | |
| Horizon | | Keystone | |Discover Service|
| | | | | (IdP) |
| | | | | |
+---^----+----^--+ +--^---+----^---++ +---^-------+----+
| | | | | | | | |
(1) (2a) (5b) (2b)(3a) (4b)(5a) (3b) (4a)
| | | | | | | | |
+---+----v----+------------+---v----+---v-----------+-------v----+
| |
| Web Browser |
| |
+----------------------------------------------------------------+
The work flow is as follows:
1) A User with a web browser reaches Horizon
2a) Horizon issues an HTTP 301 Redirect response pointing the user to
the Keystone endpoint.
2b) The browser redirects the user to a Keystone ``websso`` endpoint,
``/auth/OS-FEDERATION/websso/{saml2/oidc}`` which is protected by
saml2 and openid connect Apache plugins respectively.
3a) Since the user doesn't have an active session, the user will be
redirected to their default IdP or Discover Service where an appropriate
IdP can be chosen. Keystone will produce an appropriate <saml2:Request>
request.
3b) The browser sends a <saml2:Request> request and authenticates with the
IdP. The user also authenticates himself (e.g. with user/password
credentials)
4a) Once authentication is successful, the IdP issues a SAML assertion or
OpenID Connect claim, and redirects user back to the
``/auth/OS-FEDERATION/websso/{protocol}``.
4b) The browser redirect the user back to Keystone again, with the SAML
assertion or OpenID Connect claim.
5a) Keystone issues JavaScript code that executes upon loading by the
browser. The unscoped federated token is included in the HTML form.
5b) The user is being redirected back to the Horizon webpage, with the
unscoped federated token in the request.
All of the user interface could be maintained in Horizon, but then sensitive information is provided beyond the scoped of the Keystone service. Horizon and any other web UI would need deep integration with the Keystone WebSSO process, and the two systems would effectively be one tightly coupled system.
Describe any potential security impact on the system. Some of the items to consider include:
Note, that in order to avoid phishing and other security related attacks (a token is being transferred). Keystone needs a mechanism to register a trusted Horizon URL (possibly via an API or a config setting). This will ensure that the tokens are not posted back to an untrusted party.
None
This is primarily a visual feature. No impact on python-keystoneclient.
None
None
Primary assignee:
Other contributors:
django_openstack_auth
keystone
This specification will depend on work delivered in bp idp-id-registration
Configuration manual will have to explain how to set up the Apache server to expose a discovery service
CERN Patch to Keystone support WebSSO https://github.com/cernops/keystone/commit/66dabd94b4ad32abca171cef9192210fec289235
CERN Patch to Django-Openstack-Auth to support WebSSO https://github.com/cernops/django_openstack_auth/commit/b7e5b28a83a88b259bfaddbd754c70e1bb420447
Patchset adding remote_id attribute to the identity_provider objects https://review.openstack.org/#/c/142743/
Discovery Service specification: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf