Guide for Federation Operators

This page aims to guide Federation Operators in supporting the adoption of the Sirtfi Framework. 

Entity Attributes Filtering

The assertion of Sirtfi compliance for a Relying Party is expressed in metadata with the use of an Entity Attribute [1] as described in the OASIS documentation for asserting compliance with assurance profiles [2]. The validation strategy for local federation entity metadata might need to be reconsidered in order to allow local Entities to assert Sirtfi compliance. Additionally, if a federation has a filtering procedure in place while republishing eduGAIN metadata, federator operators need to ensure that their filtering strategy is adapted in order to facilitate the use of Sirtfi.

Two additions are necessary in the metadata of an entity asserting Sirtfi compliance so federation operators should focus on whitelisting/allowing the following :

Assurance-certification Entity Attribute

Sirtfi compliance is expressed with the use of  the Entity Attribute “urn:oasis:names:tc:SAML:attribute:assurance-certification” holding the value https://refeds.org/sirtfi in an entity’s metadata as seen below:

<EntityDescriptor ...>
   <Extensions> 
       <attr:EntityAttributes>
            <saml:Attribute 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>
       </attr:EntityAttributes> 
    </Extensions> 
... 
</EntityDescriptor>

Security Contact

A security contact element is added in every Entity that asserts Sirtfi compliance as seen below:

<ContactPerson xmlns:remd="http://refeds.org/metadata"
                contactType="other"
                remd:contactType="http://refeds.org/metadata/contactType/security">
   <GivenName>Security Response Team</GivenName>
   <EmailAddress>mailto:security@xxxxxxxxxxxxxxx</EmailAddress>
</ContactPerson>

Multiple EmailAddress tags may be defined, should an organisation wish to add both a generic email address and an individual.

This contactType has been defined within the REFEDS XSD Metadata Extension Schema.

[1] http://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-attr.html

[2] http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-assurance-profile.pdf

Coordinating Adoption

During the process of Sirtfi adoption, federation operators should anticipate providing support to entities.

Two sets of Frequently Asked Questions are provided as a first resort

• General FAQs
• Sirtfi Framework Assertions FAQs to help during an assessment of Sirtfi compliance

Please reach out to your REFEDS contacts should you, as a federation operator, require assistance. If you have no active members within REFEDS, contact us via contact@refeds.org and ask for the Sirtfi Working Group.  

Sirtfi Contact Choice

Your federation may wish to provide specific guidance on the choice of Sirtfi Contact. For more information, visit the Guide to choosing a Sirtfi Contact.

Should your federation already provide centralised federated security incident response, you may choose to leverage this existing capability.  

Metadata Extensions

How should your federation participants add the two required extensions to their metadata? The Guide for Federation Participants describes the two extensions in further detail. 

Be sure to communicate how an entity should assert their compliance and add their Sirtfi contact. Usually, federations choose to manage such metadata extensions centrally and act as the registrar. They would simply request the Sirtfi contact details from an entity via email.

Sample Outreach Letter for Federation Participants

A sample email template has been provided below to assist with outreach within your federation.