Refeds


Subject Thougths about signaling assurance level
From Pål Axelsson <pal.axelsson@xxxxxx>
Date Thu, 5 Nov 2015 10:51:47 +0000

Hi all,

 

SWAMID is about to decide and implement the second assurance level. This new assurance level has started the discussion about how to inform the service providers of what assurance level of the login.

 

We want to ask you all what you think about our thoughts.

 

Our use case

An SP wants to offer a service or parts of a service to users who fulfil SWAMID AL2.

 

Alternative 1. To signal achieved AL-level from the IdP using an attribute

 

            For SWAMID AL1/AL2 is signaled via eduPersonAssurance:

                    eduPersonAssurance: http://www.swamid.se/policy/assurance/al1

                    eduPersonAssurance: http://www.swamid.se/policy/assurance/al2

 

Advantages:

Easy to implement for the SP

Makes it possible to create a good user experience (the SP can respond differently depending on the returned ePA)

Disadvantages:

Requires logic and awareness on the SP-side in order to distinguish between AL-levels

An SP can't demand a specific level but has to verify the response. 

 

Alternative 2. To signal a desired AL-level from the SP using AuthnContextClass

 

            SP demands  AuthnContextClass "SWAMID AL1" or "SWAMID AL2" (or equiv) for access to the service (or parts of the service via stepup)

            IdP answers with used AuthnContextClass for assurance

 

Advantages:

The SP can be configured to demand the type of  AuthnContextClass that the SP is comfortable with.

Disadvantages:

Potentially complex for the SP administrator.

If the requested AuthnContextClass is not configured on the IdP it is the IdP that will present an error page to the user, not the SP.

Similar case is if/when the user is affirmed on AL1 but the SP requests AL2 (or requests MFA). The SP potentially can have problems consuming an answer depending on how the IdP is configured to reply when the requested AuthnContextClass is not met/available.

 

 

For our internal discussion about requesting authentication mechanisms? (not yet going to REFEDS)

 

SWAMIDs recommendations / implementation guidelines (to be decided - proposed)

 

All IdPs release ePA as part of the default release (i. e. to all SPs)

All IdPs are tagged with entity categories representing the SWAMID assurance level profile they fulfil

Strength of authentication (for example multifactor authentication) is handled by using AuthnContextClass

 

ToDo:

Define which AuthnContextClass that are approved in SWAMID.

We came to the conclusion that "everything" that does NOT use MFA is sort of not interesting to define as there are so many of them. (kerberos, x509, PasswordProtectedTransport etc). For these usecases we recommend looking at ePA for determining levels of Assurance.

 

What is of value and what we believe most SPs will be interested in is how to handle MFA.

SWAMID will create or reuse AuthnContextClasses that match our use cases. (logical we only see this to be used with SWAMID AL2 accounts)

RegisteredMFA (hard or soft?)

UnregisteredMFA (hard or soft?)

 

Currently we don't have any identified use cases for use of MFA with SWAMID AL1 accounts. Our recommendation will be that SPs need to be aware of and check for ePA as well as use AuthnContextClass separatly of each other where these two concepts are relevant.

 

Pål Axelsson and the rest of the SWAMID Operations team