MFA Interop Working Group

["Schwoerer, Brad" <>]

Eric,

I agree somewhat, and I think for the profile some of the them may be out of scope.  I wan't very specific on what should be communicated across the wire, just in places where it was a differentiator.  From a profile prospective though, I think what needs to be decided and why I included them, is what and how does an IDP communicate if the user did MFA and not at the request of the SP.  

-Bradley

From: Eric Goodman <>
Date: Thursday, February 18, 2016 at 11:10 AM
To: Brad Schwoerer <>, Liam Hoekenga <>, MFA Interoperability Profile Working Group <>
Subject: RE: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call)

Just to reiterate something I’ve said many times already:

 

>1) Risk based on the initial authentication [n.b., commenter’s later notes indicate IdP is making the risk decision]

This is a reasonable desire, but it is not MFA, so not something that can reasonably be communicated in an MFA (or Strong Authentication) profile. It’s additional information that I think goes beyond what we’ll get for v 1.0 of a profile.

 

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

 

This scenario is a non-starter for any form of on-the-wire communication profile or standard. If the SP is just “assuming the right thing happens” without knowing what the “right thing” is, then there is no profile in play. It is simply that the SP is trusting the default (presumably PPT) authncontext to be sufficient and is happy to know that maybe the IdP is doing something else.

 

For those on the call last week, this is the exact case I was referring to as “the SP doesn’t care that MFA was done”. The SP is presuming that successful authentication means “the right thing was done”, regardless of what actually happens. In this case there’s just a hand shake (or perhaps more appropriately a hand wave) agreement about requirements. There’s no profile to create in this case, because any information necessary to handle edge cases (“fail-open” MFA, user lost a token and needs a “pass”, whatever) cannot possibly be communicated.

 

 

An additional mode is that the SP could also indicate support for multiple contexts (e.g., MFA (presumably preferred…) or PPT), and make authz decisions on what comes back. In that case, and in either of your last two cases, I assume that the authncontexts/profiles being requested are identical (and that is the one this group is defining).

 

In the previous round of meetings we also talked about other possible signaling cases, but admittedly most of those are probably well beyond what would be in the “1.0” version (or possibly any version…) of the profile. They included things such as providing signals about what kinds of users (e.g., affiliations) will be required to use MFA (i.e., a hint to the IdP to avoid the need for a separate “step up” authentication after the user is identified) or to indicate that the authenticated user “always requires MFA for this application” (again as a hint to inform future login requests) during the step up authn.

 

--- Eric

 

 

From: [] On Behalf Of Schwoerer, Brad
Sent: Thursday, February 18, 2016 8:12 AM
To: Liam Hoekenga; MFA Interoperability Profile Working Group
Subject: Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call)

 

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
>