Use samltest.id as an example sandbox IdP

The federation documentation inconsistently references samltest.id
(formerly testshib.org, which is not well maintained) or a keystone IdP
(before keystone-to-keystone is introduced). This change switches the
examples to use samltest.id[1] and renames 'myidp' to 'samltest' where
appropriate. In the case of the WebSSO horizon configuration examples,
it's not appropriate to switch the openid examples to samltest because
samltest.id does not support OpenIDC. The examples are meant to show
that you can pair different protocols to a single IdP, so use 'acme' as
the example.

[1] https://samltest.id

Partial-bug: #1793374

Change-Id: I2633ba460182ed8ed5195a10cdaae663add8b1aa
This commit is contained in:
Colleen Murphy 2018-12-21 14:25:47 -08:00
parent 9bc2b8875d
commit 5cc61bb644
4 changed files with 43 additions and 39 deletions

View File

@ -36,6 +36,15 @@ responsible for authenticating users, and communicates the result of
authentication to keystone using identity properties. Keystone maps these
values to keystone user groups and assignments created in keystone.
In this section, we will configure keystone as a Service Provider, consuming
identity properties issued by an external Identity Provider, such as SAML
assertions or OpenID Connect claims. For testing purposes, we recommend using
`samltest.id`_ as a SAML Identity Provider, or Google as an OpenID Connect
Identity Provider, and the examples here will references those providers. If you
plan to set up `Keystone as an Identity Provider (IdP)`_, it is easiest to set
up keystone with a dummy SAML provider first and then reconfigure it to point to
the keystone Identity Provider later.
The following configuration steps were performed on a machine running
Ubuntu 14.04 and Apache 2.4.7.
@ -55,6 +64,7 @@ To enable federation, you'll need to:
``/identity`` (for example), take this into account in your own
configuration.
.. _samltest.id: https://samltest.id
.. _`SUSE`: ../../install/keystone-install-obs.html#configure-the-apache-http-server
.. _`RedHat`: ../../install/keystone-install-rdo.html#configure-the-apache-http-server
.. _`Ubuntu`: ../../install/keystone-install-ubuntu.html#configure-the-apache-http-server
@ -168,7 +178,7 @@ Provider we will use to authenticate end users:
.. code-block:: console
$ openstack identity provider create --remote-id https://myidp.example.com/v3/OS-FEDERATION/saml2/idp myidp
$ openstack identity provider create --remote-id https://samltest.id/saml/idp samltest
The value for the ``remote-id`` option is the unique identifier provided by the
IdP. For a SAML IdP it can found as the EntityDescriptor entityID in the IdP's
@ -176,7 +186,7 @@ provided metadata. If the IdP is a keystone IdP, it is the value set in that
keystone's ``[saml]/idp_entity_id`` option. For an OpenID Connect IdP, it is
the IdP's Issuer Identifier. It will usually appear as a URI but there is no
requirement for it to resolve to anything and may be arbitrarily decided by the
administrator of the IdP. The local name, here called 'myidp', is decided by
administrator of the IdP. The local name, here called 'samltest', is decided by
you and will be used by the mapping and protocol, and later for authentication.
A keystone identity provider may have multiple `remote_ids` specified, this
@ -257,7 +267,7 @@ users to the group you already created:
}
]
EOF
$ openstack mapping create --rules rules.json myidp_mapping
$ openstack mapping create --rules rules.json samltest_mapping
As another example, if Shibboleth is your IdP, the remote section should use REMOTE_USER as the remote type:
@ -287,7 +297,7 @@ As another example, if Shibboleth is your IdP, the remote section should use REM
}
]
EOF
$ openstack mapping create --rules rules.json myidp_mapping
$ openstack mapping create --rules rules.json samltest_mapping
Read more about `mapping
<https://developer.openstack.org/api-ref/identity/v3-ext/#mappings>`__.
@ -303,7 +313,7 @@ You can create a protocol like this:
.. code-block:: console
$ openstack federation protocol create saml2 --mapping myidp_mapping --identity-provider myidp
$ openstack federation protocol create saml2 --mapping samltest_mapping --identity-provider samltest
The name you give the protocol is not arbitrary. It must match the method name
you gave in the ``[auth]/methods`` config option. When authenticating it will be
@ -529,7 +539,7 @@ Create a Service Provider (SP)
In this example we are creating a new Service Provider with an ID of ``mysp``,
a ``sp_url`` of ``https://sp.keystone.example.org/Shibboleth.sso/SAML2/ECP`` and a
``auth_url`` of ``https://sp.keystone.example.org/v3/OS-FEDERATION/identity_providers/myidp/protocols/saml2/auth``
``auth_url`` of ``https://sp.keystone.example.org/v3/OS-FEDERATION/identity_providers/samltest/protocols/saml2/auth``
. The ``sp_url`` will be used when creating a SAML assertion for ``mysp`` and
signed by the current keystone IdP. The ``auth_url`` is used to retrieve the
token for ``mysp`` once the SAML assertion is sent. The auth_url has the format
@ -539,7 +549,7 @@ described in `Get an unscoped token`_.
$ openstack service provider create \
--service-provider-url 'https://sp.keystone.example.org/Shibboleth.sso/SAML2/ECP' \
--auth-url https://sp.keystone.example.org/v3/OS-FEDERATION/identity_providers/myidp/protocols/saml2/auth mysp
--auth-url https://sp.keystone.example.org/v3/OS-FEDERATION/identity_providers/samltest/protocols/saml2/auth mysp
Testing it all out
------------------

View File

@ -49,11 +49,11 @@ a *<Location>* directive for each identity provider
MellonSPCertFile /etc/apache2/mellon/sp.keystone.example.org.cert
MellonSPMetadataFile /etc/apache2/mellon/sp-metadata.xml
MellonIdPMetadataFile /etc/apache2/mellon/idp-metadata.xml
MellonEndpointPath /v3/OS-FEDERATION/identity_providers/myidp/protocols/saml2/auth/mellon
MellonEndpointPath /v3/OS-FEDERATION/identity_providers/samltest/protocols/saml2/auth/mellon
MellonIdP "IDP"
</Location>
<Location /v3/OS-FEDERATION/identity_providers/myidp/protocols/saml2/auth>
<Location /v3/OS-FEDERATION/identity_providers/samltest/protocols/saml2/auth>
AuthType "Mellon"
MellonEnable "auth"
</Location>
@ -62,7 +62,7 @@ a *<Location>* directive for each identity provider
* See below for information about how to generate the values for the
`MellonSPMetadataFile`, etc. directives.
* ``saml2`` is the name of the `protocol that you will configure <configure_federation.html#protocol>`_
* ``myidp`` is the name associated with the `IdP in Keystone <configure_federation.html#identity_provider>`_
* ``samltest`` is the name associated with the `IdP in Keystone <configure_federation.html#identity_provider>`_
* You are advised to carefully examine `mod_auth_mellon Apache
configuration documentation
<https://github.com/UNINETT/mod_auth_mellon>`_
@ -83,7 +83,7 @@ the values for the config directives `MellonSPPrivateKeyFile`,
.. code-block:: console
$ ./mellon_create_metadata.sh https://sp.keystone.example.org/mellon\
https://sp.keystone.example.org/v3/OS-FEDERATION/identity_providers/myidp/protocols/saml2/auth/mellon
https://sp.keystone.example.org/v3/OS-FEDERATION/identity_providers/samltest/protocols/saml2/auth/mellon
The first parameter is used as the entity ID, a unique identifier for this
Keystone SP. You do not have to use the URL, but it is an easy way to uniquely
@ -109,8 +109,7 @@ by the `MellonIdPMetadataFile` directive above. For example:
.. code-block:: console
$ wget --cacert /path/to/ca.crt -O /etc/apache2/mellon/idp-metadata.xml \
https://myidp.example.com/idp/saml2/metadata
$ wget -O /etc/apache2/mellon/idp-metadata.xml https://samltest.id/saml/idp
Once you are done, restart the Apache instance that is serving Keystone, for example:

View File

@ -47,7 +47,7 @@ Shibboleth module and a *<Location>* directive for each identity provider
SetHandler shib
</Location>
<Location /v3/OS-FEDERATION/identity_providers/myidp/protocols/saml2/auth>
<Location /v3/OS-FEDERATION/identity_providers/samltest/protocols/saml2/auth>
ShibRequestSetting requireSession 1
AuthType shibboleth
ShibExportAssertion Off
@ -61,7 +61,7 @@ Shibboleth module and a *<Location>* directive for each identity provider
.. NOTE::
* ``saml2`` is the name of the `protocol that you will configure <configure_federation.html#protocol>`_
* ``myidp`` is the name associated with the `IdP in Keystone <configure_federation.html#identity_provider>`_
* ``samltest`` is the name associated with the `IdP in Keystone <configure_federation.html#identity_provider>`_
* The ``ShibRequireSession`` and ``ShibRequireAll`` rules are invalid in
Apache 2.4+.
* You are advised to carefully examine `Shibboleth Apache configuration
@ -105,14 +105,7 @@ file. You will want to change five settings:
<ApplicationDefaults entityID="https://sp.keystone.example.org/shibboleth">
* Set the IdP entity ID. This value is determined by the IdP. For example, if
Keystone is the IdP:
.. code-block:: xml
<SSO entityID="https://myidp.example.com/v3/OS-FEDERATION/saml2/idp">
Example if samltest.id is the IdP:
* Set the entity ID of the Identity Provider:
.. code-block:: xml
@ -120,18 +113,20 @@ Example if samltest.id is the IdP:
* Remove the discoveryURL lines unless you want to enable advanced IdP discovery.
* Add a MetadataProvider block. The URI given here is a real URL that Shibboleth
will use to fetch metadata from the IdP. For example, if Keystone is the IdP:
* Tell Shibboleth where to find the metadata of the Identity Provider. You could
either tell it to fetch it from a URI or point it to a local file. For
example, pointing to a local file:
.. code-block:: xml
<MetadataProvider type="XML" uri="https://myidp.example.com:5000/v3/OS-FEDERATION/saml2/metadata"/>
<MetadataProvider type="XML" file="/etc/shibboleth/samltest-metadata.xml" />
Example if samltest.id is the IdP:
or pointing to a remote location:
.. code-block:: xml
<MetadataProvider type="XML" uri="https://samltest.id/saml/idp" />
<MetadataProvider type="XML" url="https://samltest.id/saml/idp"
backingFile="samltest-metadata.xml" />
You are advised to examine `Shibboleth Service Provider Configuration documentation <https://wiki.shibboleth.net/confluence/display/SHIB2/Configuration>`_
@ -182,7 +177,7 @@ to be used in a production environment):
(Set discoveryProtocol to "WAYF" for legacy Shibboleth WAYF support.)
You can also override entityID on /Login query string, or in RequestMap/htaccess.
-->
<SSO entityID="https://myidp.example.com/v3/OS-FEDERATION/saml2/idp">
<SSO entityID="https://samltest.id/saml/idp">
SAML2 SAML1
</SSO>
@ -222,7 +217,7 @@ to be used in a production environment):
<!--
<MetadataProvider type="XML" file="partner-metadata.xml"/>
-->
<MetadataProvider type="XML" uri="https://myidp.example.com:5000/v3/OS-FEDERATION/saml2/metadata"/>
<MetadataProvider type="XML" uri="https://samltest.id/saml/idp"/>
<!-- Map to extract attributes from SAML assertions. -->
<AttributeExtractor type="XML" validate="true" reloadChanges="false" path="attribute-map.xml"/>

View File

@ -60,7 +60,7 @@ If `mod_shib` is used, then use the following as an example:
ShibRequireSession On
ShibExportAssertion Off
</Location>
<Location ~ "/v3/auth/OS-FEDERATION/identity_providers/myidp/protocols/saml2/websso">
<Location ~ "/v3/auth/OS-FEDERATION/identity_providers/samltest/protocols/saml2/websso">
AuthType shibboleth
Require valid-user
</Location>
@ -73,7 +73,7 @@ If `mod_auth_openidc` is used, then use the following as an example:
<VirtualHost *:5000>
OIDCRedirectURI https://sp.keystone.example.org/v3/auth/OS-FEDERATION/websso
OIDCRedirectURI https://sp.keystone.example.org/v3/auth/OS-FEDERATION/identity_providers/myidp/protocols/openid/websso
OIDCRedirectURI https://sp.keystone.example.org/v3/auth/OS-FEDERATION/identity_providers/samltest/protocols/openid/websso
...
@ -82,7 +82,7 @@ If `mod_auth_openidc` is used, then use the following as an example:
Require valid-user
...
</Location>
<Location ~ "/v3/auth/OS-FEDERATION/identity_providers/myidp/protocols/openid/websso">
<Location ~ "/v3/auth/OS-FEDERATION/identity_providers/samltest/protocols/openid/websso">
AuthType openid-connect
Require valid-user
...
@ -105,7 +105,7 @@ If `mod_auth_kerb` is used, then use the following as an example:
Krb5Keytab /etc/apache2/http.keytab
...
</Location>
<Location ~ "/v3/auth/OS-FEDERATION/identity_providers/myidp/protocols/kerberos/websso">
<Location ~ "/v3/auth/OS-FEDERATION/identity_providers/samltest/protocols/kerberos/websso">
AuthType Kerberos
AuthName "Acme Corporation"
KrbMethodNegotiate on
@ -129,7 +129,7 @@ If `mod_auth_mellon` is used, then use the following as an example:
Require valid-user
...
</Location>
<Location ~ "/v3/auth/OS-FEDERATION/identity_providers/myidp/protocols/saml2/websso">
<Location ~ "/v3/auth/OS-FEDERATION/identity_providers/samltest/protocols/saml2/websso">
AuthType Mellon
MellonEnable auth
Require valid-user
@ -206,8 +206,8 @@ identity backend.
("credentials", _("Keystone Credentials")),
("openid", _("OpenID Connect")),
("saml2", _("Security Assertion Markup Language")),
("myidp_openid", "Acme Corporation - OpenID Connect"),
("myidp_saml2", "Acme Corporation - SAML2")
("acme_openid", "Acme Corporation - OpenID Connect"),
("acme_saml2", "Acme Corporation - SAML2")
)
3. (Optional) Create a dictionary of specific identity provider and federation
@ -223,8 +223,8 @@ protocol endpoint.
.. code-block:: python
WEBSSO_IDP_MAPPING = {
"myidp_openid": ("myidp", "openid"),
"myidp_saml2": ("myidp", "saml2")
"acme_openid": ("acme", "openid"),
"acme_saml2": ("acme", "saml2")
}
.. NOTE::