...
While this proxy model has some advantages (scalable, easy deployment from SP perspective, no SP discovery needed), it also has some weaknesses that it share with all proxy models (IdP must trust proxy, conflict with data minimization). In this work we therefore would like to find out if The following specification of an Identity Assurance Service Attribute Authority is an alternative approach making use of SAML Attribute Authority could also provide a solution, which shares some of the advantages of the proxy model but has a fewer weaknesses. Therefore, this document describes an Identity Assurance Service Attribute Authority.
Architecture
High level architecture
FIXME: Image + Description
Identity Assurance AA Architecture
The Identity Assurance AA consists of a
- SAML Attribute Authority
- SAML SP,
- web service
- database
FIXME: Image + Description
Registration Flow
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 identity vetted.
Login Flow
A normal login to a service requiring increased LoA would work like this:
- 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 (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.
In the above flow it is assumed that the registration of a second factor and any identity vetting mechanics have taken place prior to this login flow.
FIXME: Diagram of this flow
Weaknesses/Limitations
- Only works with SAML implementations supporting SAML Attribute Query (+ AttributeChecker mechanism) like Shibboleth
- Upfront configuration effort higher than with proxy
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) integrated in above flow?
- 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?