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:
parent
9bc2b8875d
commit
5cc61bb644
|
@ -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
|
||||
------------------
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
|
|
@ -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"/>
|
||||
|
|
|
@ -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::
|
||||
|
|
Loading…
Reference in New Issue