SIRTFI : A trust framework for federations

1. Why SIRTFI ?

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

2. The SIRTFI framework in a nutshell

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



3. Express SIRTFI compliance : step-by-step guide

The following chapter describes the steps to follow by an organization in order to express a SIRTFI compliance.

Step 1 - Organization self assessment

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.

Step 2 - Declaring SIRTFI compliance (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)

Step 3 - Choosing a Security contact (Federation registry)

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 :

  • Option 1 : as RENATER already provides a centralized support capacity for security incident involving the Education-Recherche federation, you can use the RENATER default email address fed-sirtfi@support.renater.fr as security contact details.
  • Option 2 : In the case where your organization already has its own security team well aware of federation concerns, you can also choose it as security contact and declare your own contact details.

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.

Step 4 – Submitting changes (Federation registry)

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.

4. Daily use of SIRTFI

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)

5. 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

6. Appendix : SIRTFI metadata extensions

6.1 SIRTFI Entity Attribute

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ...>
  <md:Extensions>
    <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>
  </md:Extensions>
  ...
</md:EntityDescriptor>

6.2 SIRTFI Security Contact

<md:ContactPerson xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
      contactType="other"
      remd:contactType="http://refeds.org/metadata/contactType/security"
      xmlns:remd="http://refeds.org/metadata">
  <md:GivenName>Security Response Team</md:GivenName>
  <md:EmailAddress>mailto:security@xxxxxxxxxxxxxxx</md:EmailAddress>
</md:ContactPerson>