workday - Re: [InC-Workday] interim workarounds for MFA
Subject: Discussion of use cases and implementation experience integrating with Workday
List archive
- From: Gary Chapman <>
- To:
- Subject: Re: [InC-Workday] interim workarounds for MFA
- Date: Thu, 16 Jul 2015 12:06:33 -0400
Your interim approach is presumably with Shibboleth IdP v2... is use of MCB required?
- Gary Chapman, NYU
On Thu, Jul 16, 2015 at 11:51 AM, Nathan A. Dors <> wrote:
Spurred by CW's message yesterday, I thought I'd start a thread on the interim solutions institutions are adopting to implement MFA with Workday today.
I think this is a useful exercise in as much as it helps sites design and deploy interim solutions that align with our collective desired future state of Workday supporting SP-initiated MFA via AuthnContextClass (assuming that's what we want).Here's our interim solution at UWash:
1. User requests Workday resource
2. User directed to our SAML IdP
3. IdP directs user to our web SSO service with “workday” as app name
4. Web SSO service verifies username and password
5. Triggered by “workday” app name, web SSO service checks to see if authenticated user is a member of the “Workday user who requires MFA” group
6. If user is a member of the group, web SSO service prompts user for and verifies OTP from MFA token.
7. Web SSO service directs back to IdP
8. IdP directs back to WorkdayThis solution requires our IAM team to implement a new user interaction flow through our web SSO service, and coordinate the related request-responses with our SAML IdP (Shib).
It also requires our functional HR/Payroll team to decide who should be in the group that requires MFA for Workday. They identified the group membership criteria by analyzing security roles in Workday, choosing MFA for those roles that have access to very confidential data, can do a mass changes to data, or can impact money that will be paid out by the University. Fortunately, these individuals generally already have MFA tokens.It has a user experience drawback in that it bluntly enforces MFA on resources that don't require it, when accessed by a user in a security role that requires MFA for access to some resources. On the other hand, it also doesn't require us to issue MFA tokens to all employees and others accessing Workday.If Workday adopts a MFA solution that can be configured based on security roles in Workday and uses AuthnContextClass, we think we'll have a relatively smooth transition from our interim solution. The implementation also, peripherally, motivates us even further to replace our aging web SSO service with Shibboleth 3.0.Michael Brogan, our IAM solution architect and workstream lead for our Workday project, has posted related project documents here:Are others adopting this same basic solution/pattern? What are some alternatives?-Nathan
- [InC-Workday] interim workarounds for MFA, Nathan A. Dors, 07/16/2015
- Re: [InC-Workday] interim workarounds for MFA, Gary Chapman, 07/16/2015
- Re: [InC-Workday] interim workarounds for MFA, David Walker, 07/16/2015
- RE: [InC-Workday] interim workarounds for MFA, Michael W. Brogan, 07/16/2015
- Re: [InC-Workday] interim workarounds for MFA, Gary Chapman, 07/16/2015
Archive powered by MHonArc 2.6.16.