SWAMID Assurance Profiles
SWAMID has two defined levels of assurance, SWAMID AL1 (http://www.swamid.se/policy/assurance/al1) and SWAMID AL2 (http://www.swamid.se/policy/assurance/al2).
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 is 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.
- An Identity Provider that has an assurance certfication in metadata for SWAMID AL2 (http://www.swamid.se/policy/assurance/al2) is allowed to assert that a user is approved for SWAMID AL2.
- An Identity Provider that has an assurance certfication in metadata for SWAMID AL1 (http://www.swamid.se/policy/assurance/al1) is allowed to assert that a user is approved for SWAMID AL1.
- An Identity Provider that has no assurance certfication in metadata is not allowed to assert that a user is approved for a SWAMID assurance profile.
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.
Expected Web Application behavior for SWAMID Assurance Profiles
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 Indentity Provider as described in the bullit 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.
REFEDS SIRTFI
"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.
Expected Web Application behavior for REFEDS SIRTFI framework
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.
Get assurance profiles from metadata in the Shibboleth Service Provider
Activate Metadata Attribute
...
Extraction for Identity Provider metadata
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
...
| Info | ||
|---|---|---|
| ||
| 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). |
Define metadata assurance certification attribute
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
...
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.
Expected Web Application behavior
If the web application need to check if a user is approved for an assurance profile the application needs to check approved assurance profiles for both the user and the used Indentity Provider as described in the bullit 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.