Configuring Shibboleth access control

From RavenWiki
Revision as of 16:30, 16 March 2009 by jw35 (talk | contribs) (Created; Apache stuff largely done)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

The example configuration files require authentication for access to all URLs with paths starting /secure. This is only intended for test and demonstration purposes and you will want to customise this behaviour so that access to URLs of your choice is controlled both by a user's ability to authenticate and the attributes made available about them.

You have three choices for implementing access control:

  • Access control decisions can be made by the SP software using configuration information in the shibboleth2.xml file. This applies to both static content and to web applications.
  • Under Apache only, access control decisions can be made by the SP software using configuration information in Apache configuration files (httpd.conf and friends, and .htaccess). This also applies to both static content and web applications.
  • For web applications only, the SP can restrict itself to authenticating the user and leave the application to make access control decisions based on the attributes of the authenticated user that the SP makes available.

In addition, for the third option, the SP con be configured not to actually require authentication but to trigger it when the user accesses a special 'virtual' url provided by the SP software.

There are a huge range of options, too many to detail here. Internet2's documentation start here

 https://spaces.internet2.edu/display/SHIB2/NativeSPProtectContent

and is likely to be useful. Below you will find various examples that concentrate on common deployment scenarios within the University.

Using Apache configuration files

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 Shibboleth SP Apache Directives for a basic summary extracted from the module source code.

Require authentication

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 SP in the federation.

 AuthType shibboleth
 ShibRequireSession On
 Require valid-user

Require Cambridge authentication

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$

Require particular users

Note that usernames, being ePPNs, have '@cam.ac.uk' on the end.

 AuthType shibboleth
 ShibRequireSession On
 Require user jw35@cam.ac.uk fjc55@cam.ac.uk

Require 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

Require lookup group membership

 AuthType shibboleth
 ShibRequireSession On
 Require groupID 100852

Require lookup institution membership

 AuthType shibboleth
 ShibRequireSession On
 Require instID CS