...
The Identity Assurance AA model consists of a
- SAML Attribute Authority (AA)
- an additional SAML SP (SAS SP, not a proxy),
- web service or IdP (SAS 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.
...
- 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 back to the SP
- The SP validates the assertion and extracts the user's attributes (at least a unique identifier that is needed for the Attribute Query).
- 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 If available, the AA returns the attributes LoA attribute (login at SAS IdP) 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 (SAS 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.
- , this time using the SAS IdP - as a substitute for a second factor of the Home IdP.
- If authentication at SAS IdP 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 factorat SAS IdP, the AA has released a LoA attribute for the user. Therefore, the AttributeChecker's requirements are met and the user is granted access.
In the above flow it is assumed that the registration of a second factor of the user with the user directory of the SAS IdP and any identity vetting mechanics have taken place prior to this login flow. The related processes may be subject to local / project / community requirements and are not in the scope of this POC implementation.
Flowchart: loa-aa-flow_v0.2.pdf
...