...
The Identity Assurance AA model consists of a
- SAML Attribute Authority
- an additional SAML SP (not a proxy),
- web service or IdP
- database
... that could be operated by a trusted third party (e.g. federation) or a research project or community. A research SP only has do perform a few configuration changes.
FIXME: Image + Description
...
- User accesses SP with his/her web browser and clicks on login
- User's web browser is sent to discovery service where users chooses his/her IdP
- User's web browser is sent to login page of his IdP where (s)he authenticates (1. factor)
- After successful authentication, the user's web browser is redirected with a SAML assertion (containing at least a unique, non-targeted identifier attribute like the eduPersonPrincipalName) back to the SP
- The SP validates the assertion and extracts the user's attributes.
- If all requested attributes have been released and the AuthnContextClassRef (or the eduPersonAssurance attribute) contains the value 'https://refeds.org/profile/mfa' we're done and the following steps are skipped.
Otherwise: - Using the identifier attribute, the SP then performs a SAML attribute query to the Attribute Authority (AA) of the Identity Assurance Service (SAS)
- The AA returns the attributes for this user to the SP
- Using the Shibboleth Attribute Checker, the SP checks if among the user's attributes there is a LoA-related attribute (that was queried from the AA). If that LoA attribute is not present or if it does not have the required value, the user is sent to a web page X of the SAS.
- Web page X is protected by an SP itself, therefore the user has to authenticate again (but he/she might not notice due to the already existing SSO session at his/her IdP) using the same IdP.
- Back on web page X, the user is asked to authenticate using a second factor.
- If authentication with second factor succeeded, a temporary LoA entry is created in database of AA and the user is sent back to SP
- SP initiates login of user again, so (s)he is sent back to his/her IdP (where SSO session is still active) and from there back to the SP, which again initiates a SAML attribute query.
- If the attribute query happened in a reasonably short time interval since the user authenticated with his/her second factor, the AA has released a LoA attribute for the user. Therefore, the AttributeChecker's requirements are met and the user is granted access.
...