summaryrefslogtreecommitdiff
path: root/doc/source/admin/federation/shibboleth.inc
blob: 95710c834048732f52c73f55d5951e36ca1dd642 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
.. -*- rst -*-

..
      Licensed under the Apache License, Version 2.0 (the "License"); you may
      not use this file except in compliance with the License. You may obtain
      a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

      Unless required by applicable law or agreed to in writing, software
      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
      License for the specific language governing permissions and limitations
      under the License.

.. _shibboleth:

---------------------
Setting up Shibboleth
---------------------

See :ref:`keystone-as-sp` before proceeding with these Shibboleth-specific
instructions.

.. note::

   The examples below are for Ubuntu 16.04, for which only version 2 of the
   Shibboleth Service Provider is available. Version 3 is available for other
   distributions and the configuration should be identical to version 2.

Configuring Apache HTTPD for mod_shib
-------------------------------------

.. note::

   You are advised to carefully examine the `mod_shib Apache configuration
   documentation`_.

.. _mod_shib Apache configuration documentation: https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig

Configure keystone under Apache, following the steps in the install guide for
`SUSE`_, `RedHat`_ or `Ubuntu`_.

.. _`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

Install the Module
~~~~~~~~~~~~~~~~~~

Install the Apache module package. For example, on Ubuntu:

.. code-block:: console

   # apt-get install libapache2-mod-shib2

The package and module name will differ between distributions.

Configure Protected Endpoints
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the Apache configuration for the keystone VirtualHost, set an additional
``<Location>`` which is not part of keystone's API:

.. code-block:: apache

   <Location /Shibboleth.sso>
       SetHandler shib
   </Location>

If you are using ``mod_proxy``, for example to proxy requests to the
``/identity`` path to keystone's UWSGI service, you must exempt this Shibboleth
endpoint from it:

.. code-block:: apache

   Proxypass Shibboleth.sso !

Configure each protected path to use the ``shibboleth`` AuthType:

.. code-block:: apache

   <Location /v3/OS-FEDERATION/identity_providers/samltest/protocols/saml2/auth>
       Require valid-user
       AuthType shibboleth
       ShibRequestSetting requireSession 1
       ShibExportAssertion off
       <IfVersion < 2.4>
           ShibRequireSession On
           ShibRequireAll On
       </IfVersion>
   </Location>

Do the same for the WebSSO auth paths if using horizon as a single sign-on
frontend:

.. code-block:: apache

   <Location /v3/auth/OS-FEDERATION/websso/saml2>
       Require valid-user
       AuthType shibboleth
       ShibRequestSetting requireSession 1
       ShibExportAssertion off
       <IfVersion < 2.4>
           ShibRequireSession On
           ShibRequireAll On
       </IfVersion>
   </Location>
   <Location /v3/auth/OS-FEDERATION/identity_providers/samltest/protocols/saml2/websso>
       Require valid-user
       AuthType shibboleth
       ShibRequestSetting requireSession 1
       ShibExportAssertion off
       <IfVersion < 2.4>
           ShibRequireSession On
           ShibRequireAll On
       </IfVersion>
   </Location>

Remember to reload Apache after altering the VirtualHost:

.. code-block:: console

   # systemctl reload apache2

Configuring mod_shib
--------------------

.. note::

   You are advised to examine `Shibboleth Service Provider Configuration
   documentation
   <https://wiki.shibboleth.net/confluence/display/SHIB2/Configuration>`_

Generate a keypair
~~~~~~~~~~~~~~~~~~

For all SAML Service Providers, a PKI key pair must be generated and exchanged
with the Identity Provider. The ``mod_shib`` package on the Ubuntu distribution
provides a utility to generate the key pair:

.. code-block:: console

   # shib-keygen -y <number of years>

which will generate a key pair under ``/etc/shibboleth``. In other cases, the
package might generate the key pair automatically upon installation.

Configure metadata
~~~~~~~~~~~~~~~~~~

``mod_shib`` also has its own configuration file at
``/etc/shibboleth/shibboleth2.xml`` that must be altered, as well
as its own daemon. First, give the Service Provider an entity ID. This is a URN
that you choose that must be globally unique to the Identity Provider:

.. code-block:: xml

   <ApplicationDefaults entityID="https://sp.keystone.example.org/shibboleth"
       REMOTE_USER="eppn persistent-id targeted-id">

Depending on your Identity Provider, you may also want to change the REMOTE_USER
setting, more on that in a moment.

Set the entity ID of the Identity Provider (this is the same as the value you
provided for ``--remote-id`` in `Identity Provider`):

.. code-block:: xml

   <SSO entityID="https://samltest.id/saml/idp">

Additionally, if you want to enable ECP (required for Keystone-to-Keystone),
the SSO tag for this entity must also have the ECP flag set:


.. code-block:: xml

   <SSO entityID="https://samltest.id/saml/idp" ECP="true">

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" file="/etc/shibboleth/samltest-metadata.xml" />

or pointing to a remote location:

.. code-block:: xml

   <MetadataProvider type="XML" url="https://samltest.id/saml/idp"
       backingFile="samltest-metadata.xml" />

When you are finished configuring ``shibboleth2.xml``, restart the ``shibd``
daemon:

.. code-block:: console

   # systemctl restart shibd

Check the ``shibd`` logs in ``/var/log/shibboleth/shibd.log`` and
``/var/log/shibboleth/shibd_warn.log`` for errors or warnings.

Configure allowed attributes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. note::

   For more information see the `attributes documentation
   <https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAddAttribute>`_

By default, ``mod_shib`` does not pass all attributes received from the Identity
Provider to keystone. If your Identity Provider does not use attributes known to
``shibd``, you must configure them. For example, `samltest.id` uses a custom UID
attribute.  It is not discoverable in the Identity Provider metadata, but the
attribute name and type is logged in the ``mod_shib`` logs when an
authentication attempt is made. To allow the attribute, add it to
``/etc/shibboleth/attribute-map.xml``:

.. code-block:: xml

   <Attribute name="urn:oid:0.9.2342.19200300.100.1.1" id="uid" />

You may also want to use that attribute as a value for the ``REMOTE_USER``
variable, which will make the ``REMOTE_USER`` variable usable as a parameter to
your mapping rules. To do so, add it to ``/etc/shibboleth/shibboleth2.xml``:

.. code-block:: xml

   <ApplicationDefaults entityID="https://sp.keystone.example.org/shibboleth"
       REMOTE_USER="uid">

Similarly, if using keystone as your Identity Provider, several custom
attributes will be needed in ``/etc/shibboleth/attribute-map.xml``:

.. code-block:: xml

    <Attribute name="openstack_user" id="openstack_user"/>
    <Attribute name="openstack_roles" id="openstack_roles"/>
    <Attribute name="openstack_project" id="openstack_project"/>
    <Attribute name="openstack_user_domain" id="openstack_user_domain"/>
    <Attribute name="openstack_project_domain" id="openstack_project_domain"/>
    <Attribute name="openstack_groups" id="openstack_groups"/>

And update the ``REMOTE_USER`` variable in ``/etc/shibboleth/shibboleth2.xml``
if desired:

.. code-block:: xml

   <ApplicationDefaults entityID="https://sp.keystone.example.org/shibboleth"
       REMOTE_USER="openstack_user">

Restart the ``shibd`` daemon after making these changes:

.. code-block:: console

   # systemctl restart shibd

Exchange Metadata
~~~~~~~~~~~~~~~~~

Once configured, the Service Provider metadata is available to download:

.. code-block:: console

   # wget https://sp.keystone.example.org/Shibboleth.sso/Metadata

Upload your Service Provider's metadata to your Identity Provider. This step
depends on your Identity Provider choice and is not covered here. If keystone
is your Identity Provider you do not need to upload this file.

Continue configuring keystone
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

:ref:`Continue configuring keystone <federation_configuring_keystone>`