Shibboleth access control using Apache configuration files: Difference between revisions
mNo edit summary |
No edit summary |
||
| (8 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
==Configuration examples== | |||
All of the following sets of directives should appear in an appropriate <Location> or <Directory> block, or in a <tt>.htaccess</tt> file. The names of attributes released by Raven on which access control decisions can be made can be found on [[Attributes released by the Raven IdP]]. Other IdPs will probably only release affiliation and targeted-id unless special arrangements are made in advance. | All of the following sets of directives should appear in an appropriate <Location> or <Directory> block, or in a <tt>.htaccess</tt> file. The names of attributes released by Raven on which access control decisions can be made can be found on [[Attributes released by the Raven IdP]]. Other IdPs will probably only release affiliation and targeted-id unless special arrangements are made in advance. | ||
There doesn't seem to be a good reference for all the Apache directives - see [[Shibboleth SP Apache Directives]] for a basic summary extracted from the module source code. | There doesn't seem to be a good reference for all the Apache directives - see [https://spaces.internet2.edu/display/SHIB2/NativeSPApacheConfig Apache Configuration for Shibboleth] in the Shib wiki, and [[Shibboleth SP Apache Directives]] for a basic summary of all attributes extracted from the module source code. | ||
===Any users=== | ===Any users=== | ||
| Line 13: | Line 13: | ||
Require valid-user | Require valid-user | ||
=== | ===Particular users=== | ||
Exactly which attributes Shibboleth uses for 'user' is controlled by the REMOTE_USER attribute of the <ApplicationDefaults> element in shibboleth2.xml. By default this is the first of the 'eppn', 'persistent-id', or 'targeted-id' attribudes that has a value. Note that when user is based on eppn it will have '@cam.ac.uk' on the end for University users. | |||
AuthType shibboleth | AuthType shibboleth | ||
ShibRequireSession On | ShibRequireSession On | ||
Require user | Require user jw35@cam.ac.uk fjc55@cam.ac.uk | ||
=== | ===Cambridge user=== | ||
Require authentication from someone in the University but don't otherwise limit who can authenticate. This is achieved with a pattern match on 'user' which in turn contains the user's eduPersonPrincipleName. | |||
AuthType shibboleth | AuthType shibboleth | ||
ShibRequireSession On | ShibRequireSession On | ||
Require user | Require user ~ @cam.ac.uk$ | ||
===Apache group membership=== | ===Apache group membership=== | ||
| Line 45: | Line 45: | ||
ShibRequireSession On | ShibRequireSession On | ||
Require groupID 100852 | Require groupID 100852 | ||
==== NOTE : Apache 2.4 ==== | |||
The Require line above needs to become: | |||
<code> | |||
Require shib-attr groupID xxxx. | |||
</code> | |||
See <https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPhtaccess> | |||
===Institution membership in lookup=== | ===Institution membership in lookup=== | ||
| Line 51: | Line 60: | ||
ShibRequireSession On | ShibRequireSession On | ||
Require instID CS | Require instID CS | ||
===More complex combinations=== | |||
Multiple values in each <tt>Require</tt> directive are 'OR'ed together so a match on any one value is sufficient to grant access. By default, multiple <tt>Require</tt> directives are also 'OR'ed together, so the following requires that the user is either a member of lookup group 100852 or is a member of lookup group 100853 or is part of the Computing Service: | |||
AuthType shibboleth | |||
ShibRequireSession On | |||
Require groupID 100852 100853 | |||
Require instID CS | |||
The <tt>ShibRequireAll</tt> directive can be used to change this so that multiple <tt>Require</tt> directives are 'AND'ed together (but note that multiple values in each individual <tt>Require</tt> are still 'OR'ed). The following requires that the user is a member of either lookup group 100852 or lookup group 100853, and is also part of the Computing Service: | |||
AuthType shibboleth | |||
ShibRequireSession On | |||
ShibRequireAll On | |||
Require groupID 100852 100853 | |||
Require instID CS | |||
Apache does not support further mixing AND and OR. | |||
===Require authentication only=== | ===Require authentication only=== | ||
| Line 67: | Line 95: | ||
Require shibboleth | Require shibboleth | ||
However if they follow a link to https://<sitename>/Shibboleth.sso/Login then this _will_ trigger authentication, after which any attributes of the user will be available to web applications which can customise their behaviour accordingly. It's useful to provide a URL to link to after the user has authenticated - use a <tt>target=</tt> parameter and supply it with a URL-escaped URL. | However if they follow a link to <nowiki>https://<sitename>/Shibboleth.sso/Login</nowiki> then this _will_ trigger authentication, after which any attributes of the user will be available to web applications which can customise their behaviour accordingly. It's useful to provide a URL to link to after the user has authenticated - use a <tt>target=</tt> parameter and supply it with a URL-escaped URL. | ||
Latest revision as of 11:58, 22 August 2017
Configuration examples
All of the following sets of directives should appear in an appropriate <Location> or <Directory> block, or in a .htaccess file. The names of attributes released by Raven on which access control decisions can be made can be found on Attributes released by the Raven IdP. Other IdPs will probably only release affiliation and targeted-id unless special arrangements are made in advance.
There doesn't seem to be a good reference for all the Apache directives - see Apache Configuration for Shibboleth in the Shib wiki, and Shibboleth SP Apache Directives for a basic summary of all attributes extracted from the module source code.
Any users
Require authentication but don't limit who can authenticate. Note, for SPs in the UK federation, that the authenticated user could be anyone with an identity on any IdP in the federation.
AuthType shibboleth ShibRequireSession On Require valid-user
Particular users
Exactly which attributes Shibboleth uses for 'user' is controlled by the REMOTE_USER attribute of the <ApplicationDefaults> element in shibboleth2.xml. By default this is the first of the 'eppn', 'persistent-id', or 'targeted-id' attribudes that has a value. Note that when user is based on eppn it will have '@cam.ac.uk' on the end for University users.
AuthType shibboleth ShibRequireSession On Require user jw35@cam.ac.uk fjc55@cam.ac.uk
Cambridge user
Require authentication from someone in the University but don't otherwise limit who can authenticate. This is achieved with a pattern match on 'user' which in turn contains the user's eduPersonPrincipleName.
AuthType shibboleth ShibRequireSession On Require user ~ @cam.ac.uk$
Apache group membership
AuthType shibboleth ShibRequireSession On AuthGroupFile /var/www/data/shib-groupfile Require group 10cc
where /var/www/data/shib-groupfile contains
10cc: jw35@cam.ac.uk kmg10@cam.ac.uk lnc@man.ac.uk
Group membership in lookup
AuthType shibboleth ShibRequireSession On Require groupID 100852
NOTE : Apache 2.4
The Require line above needs to become:
Require shib-attr groupID xxxx.
See <https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPhtaccess>
Institution membership in lookup
AuthType shibboleth ShibRequireSession On Require instID CS
More complex combinations
Multiple values in each Require directive are 'OR'ed together so a match on any one value is sufficient to grant access. By default, multiple Require directives are also 'OR'ed together, so the following requires that the user is either a member of lookup group 100852 or is a member of lookup group 100853 or is part of the Computing Service:
AuthType shibboleth ShibRequireSession On Require groupID 100852 100853 Require instID CS
The ShibRequireAll directive can be used to change this so that multiple Require directives are 'AND'ed together (but note that multiple values in each individual Require are still 'OR'ed). The following requires that the user is a member of either lookup group 100852 or lookup group 100853, and is also part of the Computing Service:
AuthType shibboleth ShibRequireSession On ShibRequireAll On Require groupID 100852 100853 Require instID CS
Apache does not support further mixing AND and OR.
Require authentication only
This forces the user to authenticate, but doesn't impose any access control. This is useful when you want to delegate access control to a protected web application. 'Require shibboleth' is a placeholder, required to trigger authentication under Apache.
AuthType shibboleth ShibRequireSession On Require shibboleth
Optional authentication
With this configuration, the Shibboleth SP won't actually require users to authenticate:
AuthType shibboleth Require shibboleth
However if they follow a link to https://<sitename>/Shibboleth.sso/Login then this _will_ trigger authentication, after which any attributes of the user will be available to web applications which can customise their behaviour accordingly. It's useful to provide a URL to link to after the user has authenticated - use a target= parameter and supply it with a URL-escaped URL.
