Skip to Content.
Sympa Menu

workday - [InC-Workday] interim workarounds for MFA

Subject: Discussion of use cases and implementation experience integrating with Workday

List archive

[InC-Workday] interim workarounds for MFA


Chronological Thread 
  • From: "Nathan A. Dors" <>
  • To: "" <>
  • Subject: [InC-Workday] interim workarounds for MFA
  • Date: Thu, 16 Jul 2015 08:51:11 -0700

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 Workday

This 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
 



Archive powered by MHonArc 2.6.16.

Top of Page