AuthN/AuthZ nuances when integrating Workspace ONE and Azure AD

Workspace ONE provides a great way to provide a seamless experience when accessing Office 365.  I’d previously written how you can integrate Workspace ONE Access with Azure AD in this blog post.

Matt Williams (End User Computing Product Manager at VMware) published three detailed articles on how you can integrate Workspace ONE Access with Azure AD too. The first article is available here.

Our clients would then ask, by integrating both solutions how does this change the Authentication (AuthN) and Authorization (AuthZ) flow between both solutions? Can I leave these applications federated with Azure AD? Can I re-federate some applications with Workspace ONE Access and why would I do this?

So to further clarify this, I put together a diagram in Miro. Miro’s a fantastic online visual collaboration tool (I don’t get any commission for recommending them!)

However before I walk you through the diagram below, first watch this excellent video titled VMware Workspace ONE Access: Conditional Access Policies – Feature Walk-through by Peter Bjork on YouTube. Peter’s video explains how Access policies are processed in more detail.

So back to the diagram. The overall AuthN/AuthZ diagram is detailed below, but it’s better if you view it directly on Miro via this link instead.

As the administrator you would have followed the instructions in the “VMware Identity Manager Integration with Office 365” so that Workspace ONE Access is the identify provider and Azure AD service for authentication to Office 365 apps. As I mentioned above, this involves some configuration in Access and running a Powershell script.

OK, so let’s go through each of the three areas of the diagram in more detail.

Login to WS1 Access Portal (IDP Initiated)

What I’m trying to articulate in this first diagram is that a user is promoted to login to their Workspace ONE Access portal (usually via a web browser) and we’re using Active Directory as the source of authentication in my example. As the administrator, you can configure a range of policies for anyone who accesses the portal in the first instance.

Most likely you’ll want to only grant access to the portal if you’ve successfully authenticated (AuthN). As per Peter Bjork’s video, Workspace ONE Access runs through a series of checks depending on the location of the end users device, then device type and finally group membership. For the default_access_policy_set (or default policy) you’re unlikely wanting to be so restrictive.

Launch Azure AD Applications

All applications that are already federated with Azure AD are treated by Workspace ONE via one access policy. In my example, I created a new policy called Azure_AD_App_Policy. This is simply a function of Azure AD when it’s integrated with another IDP. So after the user is authenticated, Azure AD then processes any authorisation (AuthZ) to those applications. For example a user might have access to Office 365, but they don’t have access to Workday.

The Workspace ONE Access policy is again processed firstly by Network Range, Device Type and Group Membership, followed by Method of Authentication, Device Compliance. You might like to configure a policy which has certificate based Authentication. Thereby providing a great end user experience (the user doesn’t need to enter their userid/password since authentication is via a certificate). Now remember the only way the user will get this certificate is if they have enrolled their device into Workspace ONE UEM.

What if they haven’t enrolled their device? Well you might deny them access or you might fall back to a policy whereby the user enters their userid/password. This is a great example for BYOD (bring your own device) users. They can still access applications even if their device isn’t enrolled.

Remember that one access policy applies to all Azure AD federated applications. Then once authenticated, Azure AD can provide a granular authorisation policy (AuthZ). So you can continue to have all of your applications remain federated with Azure AD and integrate seamlessly with Workspace ONE Access.

Launch Workspace ONE Federated Applications

What if you federate application with Workspace ONE Access? You can federate any SAML application directly with Workspace ONE (such as Jira, Salesforce etc). This is easy to do.

The reason you might federate some applications with Access, instead of leaving them federated in Azure AD is so you can provide granular access controls to each application. In my example below I’ve created an access policy called WS1_Federated_App_Policy, but I could equally create an access policy for each application.

This policy might require the users to be enrolled into Workspace ONE UEM and also have a compliant device, otherwise deny access to this application. Or similarly if the risk rating of the user was rated as high, require multi factor Authentication (MFA) using the integrated capability within Workspace ONE Intelligent Hub.

I hope this article clarifies some questions you might have had when integrating Workspace ONE with Azure AD.

If you have any questions on Workspace ONE, I’d recommend checking out the Workspace ONE community forum.  If you would like further information, you can also contact me directly via my blog contact page.

Darryl