How to ensure that only staff members of my group in my organisation can access team documents via the web and only if they are connected via the organisation’s office network? And how to implement this without writing code? Thanks to Apache, Shibboleth and a SAML-based federation like SWITCHaai, these not so uncommon real life requirements are easy to implement. At least, once one has understood how user attributes can be used for access control. This blog entry demonstrates how to create such access control rules.
Upon login of a user the Shibboleth Service Provider receives the attributes for the logged in user, for example a subset of the SWITCHaai Attributes. These attributes can then be used to compose simple to very powerful access control rules with just a few lines of configuration, either in Apache or directly within the Shibboleth Service Provider configuration. The latter has to be used to protect pages or scripts running on a Microsoft IIS webserver.
Using Apache 2.4 and Shibboleth, the solution for the above use case could be the following few lines:
[code language=”xml” highlight=”6,13,16,19″]
<Location /protected-team-documents>
AuthType shibboleth
ShibRequestSetting requireSession true
<RequireAll>
# IPv4/IPv6 Authorisation
Require ip 130.12.34.56/22 2001:12:34:56::/60
# Shibboleth Access Control directives:
# The available attribute names can be found
# in the Shibboleth attribute-map.xml
# Allow only users from organisation SWITCH
Require shib-attr homeOrg switch.ch
# Allow only staff members
Require shib-attr affiliation staff
# Allow only users from the AAI team
Require shib-attr isMemberOf aai-team
</RequireAll>
</Location>
[/code]
If the above Apache directives look unfamiliar to you even though you knew Shibboleth and Apache already, this may be because Apache 2.4 access control configuration changed quite a bit. Apache introduced new RequireAll, RequireAny and RequireNone container directives to replace the previously used Order, Allow, Deny and Satisfy directives, which are now deprecated but still supported. The effect of this is that Apache access control rules change like shown below:
| Apache 2.2 (old) | Apache 2.4 (new) |
|---|---|
| require homeOrganizationType university uas | ShibCompatWith24 On Require shib-attr homeOrganizationType university uas |
| ShibRequireAll On Require ... Require ... |
<RequireALL> Require ... Require ... </RequireALL> |
| Allow from all | Require all granted |
An overview about the most relevant changes from a Shibboleth SP administrator’s perspective are given in our AAI Tech Update presentation Apache 2.4 vs. 2.2.
A fairly extensive list of common Shibboleth access control rules can be found on our Shibboleth SP Access Control Rules page. It also contains information on how to perform access control in case the target group does not share a common attribute, or on how to implement access control in a Java web application. And for those that don’t find a suitable access control example on that page, there is now also a convenient Shibboleth Access Control Rule Wizard that allows composing Shibboleth-based access control rules by ticking a few checkboxes like shown on the screenshot below.
Using the Shibboleth Access Control Wizard or one of the many example access control rules, it should be relatively easy even for novices to compose simple but powerful access control rules using Shibboleth and the attributes used in SWITCHaai. The configuration structure for these rules changed in Apache 2.4, which requires administrators to get familiar with it. Once learned they are, however, more consistent and logical than in previous Apache versions.
