openstack
/
keystone
Code Issues Proposed changes

Add section on configuring protected auth paths 

Without this change, the federation guide does not do a good job of
explaining which URL paths should be protected by a federation-capable
auth module and why. Instead, the SP-specific guides give code samples
with no context, which makes it confusing to understand how to modify
the paths in the examples to fit one's own deployment. This change adds
that introduction.

Partial-bug: #1793374

Change-Id: I5cf940e0c54e5dd89cd3db810f8b5889a8ddce2e
This commit is contained in:
Colleen Murphy 2018-12-21 19:08:26 -08:00 committed by Colleen Murphy
parent 4d7bc6a36d
commit 708d3f4d59
1 changed files with 77 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
doc/source/admin/federation/configure_federation.rst
View File

@ -241,6 +241,83 @@ the installation guides for running keystone behind Apache for `SUSE`_,
.. _`RedHat`: ../../install/keystone-install-rdo.html#configure-the-apache-http-server
.. _`Ubuntu`: ../../install/keystone-install-ubuntu.html#configure-the-apache-http-server
Configure protected endpoints
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There is a minimum of one endpoint that must be protected in the VirtualHost
configuration for the keystone service:
.. code-block:: apache
<Location /v3/OS-FEDERATION/identity_providers/IDENTITYPROVIDER/protocols/PROTOCOL/auth>
Require valid-user
AuthType [...]
...
</Location>
This is the endpoint for federated users to request an unscoped token.
If configuring WebSSO, you should also protect one or both of the following
endpoints:
.. code-block:: apache
<Location /v3/auth/OS-FEDERATION/websso/PROTOCOL>
Require valid-user
AuthType [...]
...
</Location>
<Location /v3/auth/OS-FEDERATION/identity_providers/IDENTITYPROVIDER/protocols/PROTOCOL/websso>
Require valid-user
AuthType [...]
...
</Location>
The first example only specifies a protocol, and keystone will use the incoming
remote ID to determine the Identity Provider. The second specifies the Identity
Provider directly, which must then be supplied to horizon when configuring
`horizon for WebSSO`_.
The path must exactly match the path that will be used to access the keystone
service. For example, if the identity provider you created in `Create an
Identity Provider`_ is ``samltest`` and the protocol you created in `Create a
Protocol`_ is ``saml2``, then the Locations will be:
.. code-block:: apache
<Location /v3/OS-FEDERATION/identity_providers/samltest/protocols/saml2/auth>
Require valid-user
AuthType [...]
...
</Location>
<Location /v3/auth/OS-FEDERATION/websso/saml2>
Require valid-user
AuthType [...]
...
</Location>
<Location /v3/auth/OS-FEDERATION/identity_providers/samltest/protocols/saml2/websso>
Require valid-user
AuthType [...]
...
</Location>
However, if you have configured the keystone service to use a virtual path such as
``/identity``, that part of the path should be included:
.. code-block:: apache
<Location /identity/v3/OS-FEDERATION/identity_providers/samltest/protocols/saml2/auth>
Require valid-user
AuthType [...]
...
</Location>
...
.. _horizon for WebSSO: websso.html
Configure the auth module
~~~~~~~~~~~~~~~~~~~~~~~~~
If your Identity Provider is a SAML IdP, there are two main Apache modules that
can be used as a SAML Service Provider: `mod_shib` and `mod_auth_mellon`. For
an OpenID Connect Identity Provider, `mod_auth_openidc` is used. You can also