...
- 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) be integrated in above flow?
- Registration must be done independently, otherwise (in case an account has been hacked) an attacker might also be able to register or authenticate with a second factor
- 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?