MFA Interop Working Group

["Schwoerer, Brad" <>]

Here are the ways at I high level to think about how MFA could be triggered, 

1) Risk based on the initial authentication

2) IDP rule based – Logic in the IDM/IDP side know that the user should be stepping up authentication

3) SP initial request – All users for the SP/IDP combination need to be MFA

4) SP follow up request – User authenticated with single-factor, but now needs MFA

When looking at how/why one of the four ways would be used here are the scenarios

A)  Browser profile or IP of the user looks risky for this user, so the IDP steps up the request during authentication to be dual factor [#1]

B)  The IDM system and the SP are tied together in a way that the SP trusts that the IDM system will trigger the user through IDP to do MFA for users that need MFA.  This covers rule/role based approach, where the IDP may otherwise have sent an attribute signifying a role that the SP would have used to otherwise ask for step up.  This also covers where there are no rules but ad-hoc people that need MFA are synced between the SP and IDP or that the list is maintained by the IDP. [#2]

C)  Item B could possibly be extended by extending metadata stating a possible attribute rule with a regex type _expression_ to allow the SP to state who they want to have pre-authententicated with MFA (e.g. All users with a eduPersonEntitlement where (somethingA|somethingB). IdP can then step up user after applying SP rule to user attributes [#2]

D)  An SP is secure and all users from the IDP need to be MFA. This is in the AuthN request, if all users from all IDPs need to be MFA, this could be expressed in metadata. [#3]

E)  Some users are required to do MFA for all interaction with the SP, but not all users, and the IDP has no understanding of whom.  User does 1st factor, visits SP, SP then sees the user needs to step up, so the user is sent back with a follow up request for MFA.  [#4]

E)  Some users are required to do MFA when using certain functionality , but not all users, and the IDP has no understanding of whom.  User does 1st factor, visits SP, user interacts with the app.  User than tries doing something requiring MFA, app then sees the user needs to step up, so the user is sent back with a follow up request for MFA.  [#4]

F)  User interacts with the IDM/IDP system to let the IDP know that the user always wants to do MFA while interacting with certain SP.  [#2]

The how for each of #2-4, is I think of half of what we are focusing on.  The other half, and just as important for the profile is, how to signal to the SP that the user did MFA and in a way hopefully the SP can decide if the MFA is a way that the SP feels is strong enough.

-Bradley Schwoerer

From: <> on behalf of Liam Hoekenga <>
Date: Thursday, February 18, 2016 at 9:10 AM
To: MFA Interoperability Profile Working Group <>
Subject: Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call)

I know that the Workday example is just an example, but it sets an unmaintainable precedent should it see implementation.  I would rather see MFA triggered by a vendor-independent authentication context.

-- 

Liam Hoekenga

ITS Identity and Access Management

The University of Michigan

On Thu, Feb 18, 2016 at 9:53 AM, Belcher, C W <> wrote:

Yes, the NYU writeup is a very good summary of the MFA use cases we are looking to address with Workday.  There is also some use case info on the Workday just-in-time/step-up authentication brainstorm: https://community.workday.com/idea/90665.

Having step-up MFA via SAML with Workday is a requirement for our (UT Austin’s) go-live so we have been talking to the Workday authentication team (Chris Co, Archana Ramamoorthy) about how they can use authentication context to address it.  We are supposed to work with them on some proof-of-concept testing in the next 2 weeks.

--CW
——

C.W. BELCHER, Associate Director
Identity & Access Management  |  Information Technology Services
The University of Texas at Austin  |  512-232-6519  |  FAC 326R






On 2/17/16, 6:03 PM, " on behalf of Cantor, Scott" < on behalf of > wrote:

>On 2/17/16, 6:52 PM, "Nick Roy" <> wrote:
>
>
>
>>Now that you mention it, yep, I remember that being pretty spot on:
>>https://docs.google.com/document/d/1OV9pbXt1OmB2EOclwjFx2UIi1YnIYn2cZpJRrl5gowY/edit
>
>I had forgotten ScottK had worked on it, no omission intended.
>
>
>-- Scott
>