mfa-interop - Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call)
Subject: MFA Interop Working Group
List archive
Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call)
Chronological Thread
- From: "Bellina, Brendan" <>
- To: "" <>
- Subject: Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call)
- Date: Thu, 18 Feb 2016 16:54:56 +0000
- Accept-language: en-US
- Authentication-results: incommon.org; dkim=none (message not signed) header.d=none;incommon.org; dmarc=none action=none header.from=ucla.edu;
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
We are currently working toward a 2Q deployment with Duo and Shib IdPv3 focusing primarily on what you list as #2 below. We are leveraging extended SP profile information at the IdP and user role/group attributes. My simple high level diagram for this
is attached.
Basically we are handling:
We do not want to present the user with an isolated second factor challenge though as we believe that isolating the 2FA challenge completely from the id/password challenge may result in a confusing end user experience and could also lead users of compromised
accounts to mistakenly enable entry to attackers. So where possible, we intend to always reissue the first factor challenge immediately prior to any second factor challenge. While technically this is still step-up it will appear to the user that UP-challenge
+ 2FA challenge is an atomic unit.
Regards,
Brendan Bellina
Identity Mgmt. Architect, IT Services, UCLA
✉
☏
+1 310 206 3131
From: <> on behalf of "Schwoerer, Brad" <>
Date: Thursday, February 18, 2016 at 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
|
- Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), Cantor, Scott, 02/17/2016
- Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), Nick Roy, 02/17/2016
- Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), Cantor, Scott, 02/18/2016
- Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), Belcher, C W, 02/18/2016
- Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), Nick Roy, 02/18/2016
- Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), Liam Hoekenga, 02/18/2016
- RE: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), Cantor, Scott, 02/18/2016
- RE: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), Paul Caskey, 02/18/2016
- Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), Schwoerer, Brad, 02/18/2016
- Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), Bellina, Brendan, 02/18/2016
- RE: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), Eric Goodman, 02/18/2016
- Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), Schwoerer, Brad, 02/18/2016
- Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), David Walker, 02/18/2016
- Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), Nick Roy, 02/18/2016
- RE: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), Theresa Semmens, 02/18/2016
- Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), Belcher, C W, 02/18/2016
- Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), Cantor, Scott, 02/18/2016
- Re: Workday (was Re: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability Profile Working Group call), Nick Roy, 02/17/2016
Archive powered by MHonArc 2.6.16.