Versions Compared

Old Version 2

changes.mady.by.user Wolfgang Pempe

Saved on

compared with

New Version Current

changes.mady.by.user Wolfgang Pempe

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

(perhaps we shoud consider calling it "Step-up Authentication Service Attribute Authority" or "Authentication Assurance Service Attribute Authority"...)

Introduction

In the context of SAML-based national identity federations there has been an increasing need for learning more about a user's Level of Assurance (LoA) when it comes to identity vetting and authentication security. A few national identity federations have started to introduce services that increase the LoA of a user. All such services known today work using a proxy architecture. There is a component (the proxy) inserted between the user's Identity Provider (IdP) and the Service Provider (SP) which requires LoA information. The proxy then intercepts the user's SAML assertion and forces the user to use a second authentication factor before he can proceed to the actual service that needs LoA information. In case of the SURFconext Strong Authentication service, not only the authentication security is increased but also the identity vetting strength, as it requires the user initially to go through an identity vetting process with in-personam passport validation.

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). The following specification of an Identity Authentication Assurance Service Attribute Authority is an alternative approach making use of SAML Attribute Authority, which shares some of the advantages of the proxy model but has a fewer weaknesses.

Architecture

High level architecture

FIXME: Image + Description

...

Image Added

Authentication Assurance AA Architecture

(SAS = Step-up Authentication Service)

The Authentication The Identity Assurance AA model consists of a

  • SAML Attribute Authority (AA)
  • an additional SAML SP (SAS SP, not a proxy),
  • web service
  • database
  • 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 to make a few configuration changes. 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.Out of scope. 

Login Flow

A normal login to a service requiring increased LoA would work like this:

  1. User accesses SP with his/her web browser and clicks on login
  2. User's web browser is sent to discovery service where users chooses his/her IdP
  3. User's web browser is sent to login page of his IdP where (s)he authentications (1. factor)authenticates
  4. 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
  5. The SP validates the assertion and extracts the user's attributes (at least a unique identifier that is needed for the Attribute Query).
  6. 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. (NB: This is only an example. Which access rules are implemented is up to the community or project making use of this approach!)
    Otherwise:
  7. Using the identifier attribute, the SP then performs a SAML attribute query to the Attribute Authority (AA) of the Identity Assurance Service Step-up Authentication Service (SAS)
  8. The If available, the AA returns the attributes LoA attribute (login at SAS IdP) for this user to the SP
  9. 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.
  10. 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.
  11. Back on web page X, the user is asked to authenticate using a second factor.
  12. , this time using the SAS IdP - as a substitute for a second factor of the Home IdP.
  13. 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
  14. 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.
  15. 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 the user with the user directory of the SAS IdP and any identity vetting mechanics have taken place prior to this login flow. FIXME: Diagram of this The related processes may be subject to local / project / community requirements and are not in the scope of this POC implementation.

Image Added

Flowchart: loa-aa-flow_v0.2.pdf flow

Weaknesses/Limitations

  • Only works with SAML implementations supporting SAML Attribute Query (+ AttributeChecker mechanism) like Shibboleth
  • Upfront configuration effort higher than with proxy

Strengths:

  • Less problematic from a data minimization point of view because no proxy between user’s Home IdP and SP. Therefore no need to get super set of all attributes. The SAS SP that triggers the authentication at SAS IdP only needs a unique identifier..

  • For the user’s Home IdP the SAS SP that verifies the second authentication is just like any other SAML SP, which needs an identifier attribute.

  • The trusted third party / research community or project operating the SAS components is able to implement identity vetting processes (or even 2FA) that best meet their needs.  

  • The user’s identity (esp. affiliation with HO) does not change

Open Questions

  • How to transport the information that a second factor has been used for authentication?
  • 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?
    • 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)

References