Cliquez ici pour la version française

Filtering at the SP side based on SIRTFI

At the Shibboleth SP side, you have the possibility to implement user filtering based on SIRTFI. The main idea here is to restrict access only to the users authenticated against a SIRTFI compliant IDP.

From a technical point of view, there are at least two means how to achieve it :

  • Either at the application level, by using the access control logic implemented in your application ;
  • Or directly by using the filtering feature offered by the Shibboleth SP.

In both cases, you have beforehand to retrieve the SIRTFI entity attribute at the SP side.

Retrieving SIRTFI entity attribute on the SP side

Entity attributes are listed in federation metadata. They can be mapped in Shibboleth SP similarly to users' attributes released by IdPs. To utilize entity attributes, it is required to set a prefix for metadata attributes in ApplicationDefaults element (or ApplicationOverride element) within shibboleth2.xml configuration file like so :

shibboleth2.xml
<ApplicationDefaults entityID=https://example.org/shibboleth/
metadataAttributePrefix="md_">

Say, there is the following SIRTFI entity attribute defined for an IDP in the metadata :

<mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
  <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                  NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
                  Name="urn:oasis:names:tc:SAML:attribute:assurance-certification">
           <saml:AttributeValue>https://refeds.org/sirtfi</saml:AttributeValue>
  </saml:Attribute>
</mdattr:EntityAttributes>

Then, we can define attribute mapping for the Shibboleth SP in attribute-map.xml this way:

attribute-map.xml
<Attribute name="urn:oasis:names:tc:SAML:attribute:assurance-certification" id="sirtfi" />

As a result the above defined attribute value is available through the md_sirtfi variable

Using the access control logic of the application

Once the variable md_sirtfi is retrieved in the Shibboleth SP, the corresponding value can be passed to the application.
If you are able to modify the source code of your application, then you can consider implementing and access control which will check this value.

Using the filtering feature of the Shibboleth SP

As an alternative solution, you can also use the filtering feature of the Shibboleth SP.
In Apache, you just need to define a directory (/limit/access) to which you would like to restrict access and where the rules defining authorization are placed (/path/to/ac.xml):

<Directory /limit/access>
    AuthType shibboleth
    ShibRequestSetting requireSession 1
    ShibAccessControl /path/to/ac.xml 
</Directory>

The configuration of the Shibboleth SP filter is defined in the /path/to/ac.xml file, as shown in the example below :

Example of a basic filter checking that the user is a student authenticated to a trusted IDP (SIRTFI compliant IDP):

<AccessControl type="edu.internet2.middleware.shibboleth.sp.provider.XMLAccessControl">
   <AND>
      <Rule require="md_sirtfi"> https://refeds.org/sirtfi </Rule>
      <RuleRegex require="affiliation">^student@.+\.cz$</RuleRegex>   		
   </AND>
</AccessControl>

The example above remains basic but you can implement more advanced access control rules. Consult the official shibboleth documentation for more details :
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPXMLAccessControl