Configuring Shibboleth access control: Difference between revisions

From RavenWiki
Jump to navigationJump to search
(IIS under construction)
No edit summary
 
(3 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{New Docs}}
The example configuration files require authentication for access to all URLs with paths starting <tt>/secure</tt>. 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.  
The example configuration files require authentication for access to all URLs with paths starting <tt>/secure</tt>. 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.  


Line 4: Line 6:
* 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.
* 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.
* 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.
* Access control decisions can be left to a web application with the SP restricting itself to authenticating the user and providing attributes to the application. Obviously this only applies to protection of web applications.


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.  
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, a set up sometimes called 'lazy session establishment'.


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


   https://spaces.internet2.edu/display/SHIB2/NativeSPProtectContent
   https://wiki.shibboleth.net/confluence/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 <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.
 
===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 SP in the federation.
 
  AuthType shibboleth
  ShibRequireSession On
  Require valid-user
 
===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$
 
===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
 
===Apache group membership===
 
  AuthType shibboleth
  ShibRequireSession On
  AuthGroupFile /var/www/data/shib-groupfile
  Require group 10cc
 
where <tt>/var/www/data/shib-groupfile</tt> contains
 
  10cc: jw35@cam.ac.uk kmg10@cam.ac.uk lnc@man.ac.uk
 
===lookup group membership===
 
  AuthType shibboleth
  ShibRequireSession On
  Require groupID 100852
 
===lookup institution membership===
 
  AuthType shibboleth
  ShibRequireSession On
  Require instID CS
 
===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. '<tt>Require shibboleth</tt>' 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 <tt>target=</tt> parameter and supply it with a URL-escaped URL.
 
==Using the shibboleth2.xml file==
 
Authentication requirements and access control rules can be defined in the shibboleth2.xml configuration file. This is the only way that will work with IIS; with Apache it's possible to configure rules both in shibboleth2.xml and in the Apache configuration files (with the Apache files taking precedence) but that way madness lies - it's much simpler to use one or the other.
 
This process uses additional XML elements inside a <RequestMap> element in the <RequestMapper> element of the configuration file. See [[editing XML]] for hints about editing this XML file.
 
===IIS Considerations===
 
===Apache considerations===
 
===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 SP in the federation.
 
===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.
 
===Particular users===
 
Note that usernames, being ePPNs, have '@cam.ac.uk' on the end.
 
 
===Apache group membership===
 
===lookup group membership===
 
===lookup institution membership===
 
===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. '<tt>Require shibboleth</tt>' is a placeholder, required to trigger authentication under Apache.
 


===Optional authentication===
and is likely to be useful. We also have a set of examples of
* '''[[Shibboleth access control using shibboleth2.xml | Using shibboleth2.xml]]'''; and
* '''[[Shibboleth access control using Apache configuration files | Using Apache configuration files]]'''

Latest revision as of 11:41, 3 March 2020

We're working on improving Raven resources for developers and site operators.

Try out the new Raven documentation for size.

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.
  • Access control decisions can be left to a web application with the SP restricting itself to authenticating the user and providing attributes to the application. Obviously this only applies to protection of web applications.

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, a set up sometimes called 'lazy session establishment'.

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

 https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPProtectContent

and is likely to be useful. We also have a set of examples of

Retrieved from "https://wiki.cam.ac.uk/wiki/raven/index.php?title=Configuring_Shibboleth_access_control&oldid=2917"