Workspace ONE - Single Sign-On for Legacy Web Apps with Secure Access

I've been working with a few customers lately which have had unique use cases, which I don't see very often.  I thought it would be worth discussing how we solved their issue and lab it up to share. 

 Requirements:
  • Use the Workspace ONE portal for *all* applications
  • Provide SSO wherever possible
  • Provide access to content previously only available internally
Challenging Applications:
  • SharePoint 2010 configured with Kerberos Auth
  • IIS written apps with basic auth
  • IIS written apps with header based auth
  • Non-IIS apps with local user repos (not connected to AD)
Investigating the requirements, I thought this a job for a Workspace ONE component which doesn't come up much, the Unified Access Gateway (UAG). The UAG since verison 2.9 has had the ability to "Identity Bridge."  Beyond the fancy terminology this simply means take one form of AuthN and convert it to another.  In this case Workspace ONE (vIDM) will send a SAML assertion to UAG,  UAG consumes and validates this SAML assertion and can convert that to a Kerberos ticket, insert a Header, or nothing.  All of those "Identity Bridging" techniques can be combined with the ability to Reverse Proxy.  
Image Courtesy of docs.vmware.com

Single Sign-On

If we dissect our challenging applications 1 by 1.....
  • SharePoint 2010 configured with Kerberos Auth
For SharePoint we will simply use the Identity Bridge feature to request a Kerberos ticket, using a service account, to request a Kerberos ticket on behalf of the user.  As SharePoint is already setup for Kerberos this is an easy configuration.
  • IIS written apps with basic auth
For the internally developed application written for IIS and using Basic Auth (401 challenge) we need to reconfigure the application in IIS to accept Kerberos. Doing so will enable us to provide SSO. A good Microsoft article to do so:
  • IIS written apps with header based auth
For the IIS site which reads a header a bit of investigation needs to be done.  Probing questions to ask:
  1. What is the header name and expected value?
  2. Does providing this header 'authn' to the application?
  3. Can we confirm this 'header' is in fact a header and not part of the URL or a Cookie?
Essentially, from my experience, I have seen where the app is written to look for a header containing the user's UPN.  The app assumes that the front end 'control' has validated the user, and is sending the identity over.   
  • Non-IIS apps with local user repos (not connected to AD)
Here there is not much Identity Bridging to be done. What we can do is make the 'Web App' available in the Workspace ONE portal. When the user clicks it a SAML assertion is sent to the UAG for validation.  This will allow only authenticated users to the Workspace ONE conditional policy authentication engine to get network access to the 'Web App.'  After that unfortunately the app will ask for a local credential.  I'd score our ability to ingest this type of 'Web App' as a 5/10. Network access allowed but failed at Single Sign-On.


Secure Access

One nice piece is I worked with a customer with the concept that everything is external to the datacenter, even if hardwired into the internal network. This customers security was based on a SSL VPN which went through 2factor authentication.  With Workspace ONE and Identity Bridging we replaced the need for their traditional VPN.  With the Unified Access Gateway sitting in their DMZ behind a load balancer with a public IP we allowed access to those internal 'Web Apps' through regular Https protocols.  The UAG was setup to only Reverse Proxy those 'Web Apps' if it was provided a valid SAML assertion from Workspace ONE (vIDM).  
I hope to write, co-write, or link to a Step-by-Step guide for Identity Bridging soon.  The VMware public documentation makes a lot of assumptions that you know Kerberos, Reverse Proxying, Regex patterns, etc very well.   Stay tuned.


Comments

Post a Comment