I will be missing today’s meeting because of a conflict. Sorry.
Theresa
Theresa Semmens, CISA
NDSU Chief Information Security Officer
Director, Records Management
Office: 210D Quentin Burdick Building
Mail: NDSU Dept 4500
PO Box 6050
Fargo, ND 58108-6050
P: 701-231-5870
F: 701-231-8541
E:
www.ndsu.edu/its/security
From: [mailto:]
On Behalf Of Nick Roy
Sent: Thursday, February 18, 2016 1:51 PM
To: David Walker <>;
Subject: Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call)
I'll miss today's call due to a conflict with a Kantara WG-FI call, my regrets.
From:
<> on behalf of David Walker <>
Date: Thursday, February 18, 2016 at 10:57 AM
To: "" <>
Subject: Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call)
Just catching up on this thread. A lot of great information!
We can talk more about this in our call later today, but to answer the specific question for Karen and me, yes; we'll link up with the WorkDay group. Also, I suspect this has raised more questions for the table we'll be discussing this afternoon. (In our
"live scribe" document.) You'll notice there are blank rows in that table...
David
On 02/18/2016 09:10 AM, Eric Goodman wrote:
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.
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.
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
>
|
