The growth and inter-connection of federations through eduGAIN has created a new vector of attack. One compromised account can provide access to a multitude of services across the inter-federation community.
This occurs in a context where the quality of operational security at organisations is variable and often unknown to other participants. There is typically no minimum level of security to join a federation. Consequently, there is no guarantee of effective collaboration between organisations in the event of a federated incident.
The SIRTFI framework (Security Incident Response Trust Framework for Federated Identity) adress this issue. It provides a mechanism to identify trusted, operationally secure eduGAIN participants and facilitate effective incident response collaboration.
SIRTFI is an initiative of the REFEDS SIRTFI working group (Research and Education FEDerations group) : https://refeds.org/sirtfi
The SIRTFI framework defines a set of security rules and best practises, structured around the four following fields : operational security, incident response, traceability and participant responsabilities
The table below details in a synthetic view each field covered by the framework :
| Security Field || Description
| Operational Security [OS] || - Regular patches
- Processes for vulnerability management
- Intrusion detection and information protection
- Possibility of timely user rights changes
- Established contacts for service owners and users
- Security Incident Response
| Incident response [IR] || - Security incident response contact information
- Timely reply to other SIRTFI members
- Collaborate in management of security incidents
- Respect security incident response procedures of own organisation
- Respect user privacy
- Respect Traffic Light Protocol (Traffic Light Protocol)
| Traceability [TR] || - Keep accurate logs of all relevant information available for handling security incidents
| Participant Responsabilities [PR] || - Acceptable use policy (AUP)
- User consent to AUP
The following chapter describes the steps to follow by an organization in order to express a SIRTFI compliance.
The first step for an organization consists in completing a self assessment following the SIRTFI Framework (see previous chapter).
Your organisation is SIRTFI compliant if you are able to agree with each and every statement included in the framework
In the case where the assessment is positive, then the organisation can declare this compliance for each of the federated resources (IdP or SP) it owns. This operation is performed through the Federation registry.
This operation is performed through the Federation registry, from the editing page of the involved resource (IDP or SP). Under the “contatcs” tab, you only have to tick the dedicated box in order to attest this ressource is compliant.
Warning : by ticking the box ”I certify that this SAML entity complies with the SIRTFI requirements”, you agree to comply with each and every statements of the SIRTFI framework.
After ticking the box, then you have to define a security contact for this resource (the fields security contact name and emails , grayed so far, become writable)
The security contact will be the initial point of contact during a federated incident involving this resource.
As a member organization of the Education-Recherche federation, you have 2 choices to select a SIRTFI contact for your resource :
The security contact of a resource should be an individual or group who has agreed to perform the incident response obligations of the Sirtfi Framework on behalf of the entity.
Submitting the form with the above changes on the Federation registry results in adding two SIRTFI extensions (SIRTFI entity attribute et Security Contact) in the metadata of your resource.
A example of these two SIRTFI metadata extensions is given in chapter 6.
For a compliant organization , the use of SIRTFI on a daily basis will mainly consist of the following tasks :
1. Collaborating to the security incident response process :
In the event of an incident involving a federated entity or user, contact the relevant security contact listed in metadata ;
If you are contacted for help in an external incident, you are obliged to respond and actively collaborate with other Sirtfi compliant entities.
2. The possibility if you are in charge of an SP, to restrict authentication to only those IdPs who are also trusted (i.e SIRTFI compliant) with the implementation on specific filtering at the SP side (see chapter 5 for more details)
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.
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 :
Say, there is the following SIRTFI entity attribute defined for an IDP in the metadata :
Then, we can define attribute mapping for the Shibboleth SP in attribute-map.xml this way:
<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
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.
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):
ShibRequestSetting requireSession 1
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):
<Rule require="md_sirtfi"> https://refeds.org/sirtfi </Rule>
The example above remains basic but you can implement more advanced access control rules. Consult the official shibboleth documentation for more details :
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ...>
<md:GivenName>Security Response Team</md:GivenName>