...
FIXME: Description of what is needed for the very first request to the SP to set up the user's second factor and get his/her identity vetted.
Login Flow
...
- 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 authentications 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.
- 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.
...
- Only works with SAML implementations supporting SAML Attribute Query (+ AttributeChecker mechanism) like Shibboleth
- Upfront configuration effort higher than with proxy
- Provides only low security. In case an account has been hacked, the attacker might also be able to perform the 2nd factor authentication:
- email password is often identical with the one of the general user account
- no independent / external identity vetting
Open Questions
- How could initial identity vetting procedure be integrated in above flow?
- Where would vetted attributes come from, AA or IdP?
- How and by which component can be expressed which identity data was vetted?
- How could registration of second factor (e.g. SMS token) be integrated in above flow?
- Dedicated (central) IdP or equivalent web service
- Identity vetting?
- What are the security implications of this scenario?
- Are there ways to make the AA release LoA information for the wrong user?
- Is it a problem that the first and the second factor are checked by two different components?
- Are there ways to fool the AttributeChecker and get around it?
- What can/should be done to prevent that a user's IdP can assert the LoA value instead of the AA?