...
- SAML Attribute Authority
- SAML SP,
- web service or IdP
- database
LoA Attributes: eduPersonAssurance, based on the recommendations of the REFEDS Assurance WG
FIXME: Image + Description
...
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.
Flowchart: loa-aa-flow_v0.12.pdf
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 to transport the information that a second factor has been used for authentication?
- AuthnContextClassRef: https://refeds.org/profile/mfa (cf. https://wiki.refeds.org/display/CON/Consultation%3A+REFEDS+MFA+Profile)
- LoA Attribute: eduPersonAssurance, based on the recommendations of the REFEDS Assurance WG
- 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?
- As for the POC, the second factor tokens will be registered (i.e. assigned to users) by the service administrator.
- 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? (in case the IdP is not considered to be trustworthy)