Discussion of use cases and implementation experience integrating with Workday

[David Walker <>]

FYI, there's been progress on the MCB for IdPv3 front.  See the Multi-Context Broker page on the InCommon Assurance page for more details.  IdPv3 has the basic MCB functionality in the base system, so our approach is to document the MCB Model, and then describe how to configure the model in IdPv3, rather than to re-implement the MCB software.  Dave Langenberg of the University of Chicago already has IdPv3 supporting Password, Duo (using an IdPv3 authentication flow recently released by Unicon), and InCommon Silver.

David

On 07/16/2015 09:06 AM, Gary Chapman wrote:

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 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:

https://wiki.cac.washington.edu/x/cRQOB

Are others adopting this same basic solution/pattern? What are some alternatives?

-Nathan