SWAMID has three defined levels of assurance, SWAMID AL1 (), SWAMID AL2 () and SWAMID AL3 ().
All by SWAMID approved assurance levels for an Identity Provider are defined in the SAML metadata as a SAML extended attribute urn:oasis:names:tc:SAML:attribute:assurance-certification. The assurance certfication attribute in metadata defines what assurance profiles the Identity Provider and it's home organisation has been approved for or has declared that ther fulfill.
The Identity Provider uses the attribute eduPersonAssurance to assert the logged in user's assurance profle. Please observe that the Identity Provider must not indicate any other assurance profile than it's approved for. Signaling the user's assurance profile via the attribute eduPersonAssurance means that the user verfication fulfills all parts of the asserted assurance profile. Attribute mapping for eduPersonAssurance is defined as assurance in 3.2 Configure Shibboleth SP - attribute-map.xml.
To check a user's assurance profile you need to check that the Identity Provider is approved for the same assurance profile as it has asserted for the user. To do this you need to activate extendend functionality in the Shibboleth Service Provider. This extension is available since version 2.2.
If the web application need to check if a user is approved for an SWAMID Assurance Profile the application needs to check approved assurance profiles for both the user and the used Identity Provider as described in the bullet list in this document.
Please note that this approach only checks that the Identity Provider and the user fulfills the checked assurance profile. To check that the credentials used to log in fulfills the assurance profile is more advanced and needs more configuration of both Service Provider and Identity Provider.
"The Security Incident Response Trust Framework for Federated Identity (Sirtfi) aims to enable the coordination of incident response across federated organisations. This assurance framework comprises a list of assertions which an organisation can attest in order to be declared Sirtfi compliant." The purpose with REFEDS SIRTFI (https://refeds.org/sirtfi) framework is to add trust based on a defined Best Current Practice on incident response and operational security.
All Identity Providers that has declared that they follow the REFEDS SIRTFI framework are defined in the SAML metadata as a SAML extended attribute urn:oasis:names:tc:SAML:attribute:assurance-certification. The assurance certfication attribute in metadata defines what assurance profiles the Identity Provider and it's home organisation has declared that they fulfill or has been approved for.
Service Providers can also via metadata declare that they fulfill the REFEDS SIRTFI framework and that gives the Identity Providers added trust in that the Service Providers fulfills the same Best Current Practrice.
If the web application need to check if an Identity Provider has delcared that they fulfill the security framwork REFEDS SIRTFI the application needs to check approved assurance profiles the Indentity Provider metadata. The web application may also use a filter in the Discovery Service that narrow down the shown Identity Providers to only those who fulfills the framework.
To get the approved assurance profiles from metadata you need to activate the Metadata Attribute Extraction extension in Shibboleth SP. This is done by extending the ApplicationDefaults tag in shibboleth2.xml by adding metadataAttributePrefix="Meta-" after REMOTE_USER="...", see example. This is a standard example in the file example-shibboleth2.xml in later versions of Shibboleth SP. It is also included in the SWAMID Configure Shibboleth SP - SWAMID-shibboleth2.xml
<ApplicationDefaults entityID="https://example.com/shibboleth" REMOTE_USER="eppn persistent-id targeted-id" metadataAttributePrefix="Meta-">
|Please note that you may get to many headers after activating this extension. If you do, please remove all unused attributes from attribute-map.xml or modify backend header limits (LimitRequestFields/LimitRequestFieldSize in Apache HTTPD Server, maxHeaderCount/maxHttpHeaderSize in Apache Tomcat Connectors).|
Next step is to make approved assurance levels available in the application. This is done attribute-map.xml the same way as normal Identity Provider asserted attributes. It is also included in 3.2 Configure Shibboleth SP - attribute-map.xml
<Attribute name="urn:oasis:names:tc:SAML:attribute:assurance-certification" id="Assurance-Certification"/>
After the activation of Metadata Attribute Extension and the attribute definition all Identity Provider approved assurance profiles are available in the multi-valued attribute Meta-Assurance-Certification.