Skip to Content.
Sympa Menu

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:
  • Sensitive resource requiring all user stop use MFA to access – this would be managed at the IdP by checking data that extends the SP profile
  • Privileged account requiring MFA for all resources – the IdP would look for a specific attribute value pair on the account
  • Selective MFA for a user for a specific resource – the SP profile at the IdP would be extended to store a specific attribute value pair. When the user has that pair MFA would be enforced.
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





Archive powered by MHonArc 2.6.16.

Top of Page