Featured Post

Using VMware's Horizon Performance Tracker For Rudimentary Blast Optimization

Recently updated for Horizon 7.10, the  VMware Blast Extreme Optimization Guide  focuses on, "two key configurable components: the tran...

Wednesday, December 30, 2020

Wrapping VMware's Workspace ONE Security Around G Suite Consumption

Recently I helped design an integration between G Suite (Google Workspace) and VMware's Workspace ONE.  A key objective of the design is to secure G Suite on mobile devices by requiring UEM enrollment for access to services like Gmail or Google Drive.  While phones in a BYOD scenario are a primary focus, the solution accommodates an entire enterprise and range of endpoints including tablets, desktops, and laptops.  Overall, the challenge of securing G Suite across multiple domains and various device types is met through a combination of WS1 Access and UEM, with an option to layer on additional security and automation through WS1 Intelligence.  


The solution traverses a well-traveled and documented path for WS1, essentially the same strategy we'd employ for securing any SAML compliant application with WS1. Look at the graphic above.  Replace the images of G Suite with a logo for Office 365, Salesforce, ServiceNow, Workday, Slack or Zoom.  The relevant steps, strategies and capabilities are generally the same: perform a SAML federation, leverage mobile SSO, and use conditional access policies to judiciously enforce relevant security.  It's a standard WS1 formula for enabling traditional IT shops to securely embrace SaaS adoption. 


An Overview Of The Solution


When it comes to the more advanced security capabilities of Workspace ONE, SAML is the star of the show.  Fortunately, most modern SaaS solutions, including G Suite, support SAML and so stand to gain tremendously from Workspace ONE.  Typically, an integration occurs directly between WS1 Access and the SaaS solution, however, it can also happen through the intermediary of a 3rd party IDP such as Okta, Ping or ADFS.  Regardless, from the user's perspective the end result is usually the same: they're able to leverage their on-premises AD identity and associated authentication methods for secure access to a SaaS based solution.  This article will initially focus on a direct integration between WS1 and G Suite,  then elaborate on options for 3rd party IDPs a bit later on. 




















The basic idea with SAML is to have a trust established between an identity provider (IDP) and service provider (SP) through an exchange of metadata and a cert.   Then, going forward, whenever anyone wants access to the service provider they must first prove their identity to the IDP through whatever authentication methods it accepts and enforces.  It could be as simple as basic AD authentication or as complex as Mobile SSO based on device compliance.  Regardless, once the user's identity has been proven to the satisfaction of the identity provider, the IDP will issue the user agent, typically a browser, a SAML assertion that is then forwarded to the service provider in exchange for access to the service.  An absolutely amazing overview of SAML by Peter Pjork called, SAML 2.0: Technical Overview, is available on YouTube as well as VMware's TechZone.   Below is one of my favorite graphics from this enablement.   


















In the G Suite integration detailed in this post WS1 Access is the identity provider while the G Suite tenant is the service provider.   This SAML federation is the absolute backbone of the integration, first and foremost enabling users to access G Suite with their AD credentials.  Further, it provides SSO and opens up G suite to a wide range of authentication methods, most notably conditional access based on device posture and compliance.  In a nutshell most of the goodness discussed in this post is rooted in this SAML federation.   The flow of this article is structured accordingly, starting with the G Suite SAML federation, then working through Mobile SSO, conditional access polices, device trust, and WS1 intelligence.   It will also review some of the finer points of the integration particular to G Suite.    Here's the basic outline for this post: 

  • SAML Integration Between G Suite (Google Workspace) And WS1 Access 
  • Mobile SSO for iOS and Android
  • Conditional Access Policies 
  • Device Trust And 3rd Party IDPs
  • WS1 Intelligence
  • G Suite Specific Considerations:
    • Pushing Out Email Profiles To Mobile Devices
    • Token Revocation 
    • DLP

With that said, I'll start with a review of the initial federation between G Suite and WS1 Access. 


SAML Integration Between G Suite (Google Workspace) And WS1 Access



















For guidance on a direct SAML integration between G Suite and WS1 Access, I turned to the blog, "How To Integrate G Suite With Workspace ONE Access?",  by Aamir Khan.  Following the steps detailed in this article was relatively straight forward and having it's guidance as a tailwind was extremely helpful. Lining up the pre-requisites was significantly more work than the actual SAML integration.  Steps like getting a test domain setup, deploying a WS1 Access Connector and signing up for a G Suite eval tenant took me an evening, while the actual SAML integration itself was less than a 20 minute affair.  The article breaks down the SAML integration into these 3 major steps: 
  1. Configuring the Google App within WS1 Access
  2. Downloading the Signing Certificate From WS1 Access
  3. Configuring SSO In The Google Admin Console 
While these steps aren't exactly intuitive or for the faint of heart, the blog post lays things out quite nicely. Executing the recipe involved switching back and forth between Aamir's blog post, my WS1 tenant and my Google Admin console.   Essentially it was all plug 'n chug, replacing variables with the specifics of my environment like the G Suite primary domain name and the WS1 Access tenant url.  For instance, here's a screenshot of me updating the preconfigured Google App template in WS1 Access with info about my G Suite tenant at BellflowerBlues.com. 




















Plug and chug, plug and chug:  
















Then, downloading the signing certificate was a matter of navigating to Catalog --> Web Apps --> Settings ---> SAML Metadata on my WS1 Access tenant.  From there you can just hit the download button and you'll have the signing certificate. 















Finally, there's the configuration of the WS1 Access tenant as an identity provider for G Suite. Again, just some plug 'n chug, updating the G Suite tenant with info about my WS1 Access tenant and uploading the signing certificate.  


With the integration between WS1 Access and G Suite complete I had the full breadth of the WS1 Access tenant's authentication methods and conditional access policies at my disposal   That's no small thing and something I'm going to elaborate on in a bit.   However, I want to first zero in on the mobile use case and SSO for G Suite applications.     At this point, without further configuration on the UEM side of the equation, mobile G Suite user's are handed off to the WS1 Access tenant for authentication, similar to your normal desktop and laptop users.   Here's a quick demo of what that looks like: 



While this is fine and good, we can certainly enhance this mobile G suite experience using Mobile SSO for iOS and Android. 


Mobile SSO For iOS And Android 


Mobile SSO is a solution from VMware that offers SSO for mobile applications on iOS or Android.   It enables the use of certificate authentication for mobile apps with backends that have been federated with WS1 Access through SAML.  Through a combination of WS1 UEM and WS1 Access, certificate authentication is completely managed and secured on behalf of the mobile app.  Peter Bjork offers a wonderful review of this feature 5 minutes into the video, "Workspace ONE. Access: Feature Walk Through."   Mobile SSO enables VMware customers to overcome traditional challenges with leveraging certificate authentication for mobile apps, "offering near 100% application support," for any mobile solutions that have been federated with WS1 Access. 


When it's implemented for a mobile app, at login time, once a username has been provided, Mobile SSO will kick in, completing the login process for the user.  By enabling certificate use for mobile apps Mobile SSO arguably achieves the remarkable feat of both increasing usability and security.   In the context of a G Suite deployment, particularly in regard to Gmail, it absolutely shines, enabling a simpler user experience accessing email through either the Gmail mobile app or native iOS mail client. Here's a demo of the login process:


While Mobile SSO is a mature and proven solution, it can be a little intimidating to setup.  For guidance on Mobile SSO for iOS, check out this post I published a couple years ago, "Configuring Mobile SSO For iOS In Workspace ONE UEM."  There's also the official guidance from the Workspace ONE Access side of the house, Configuring Mobile SSO for iOS Authentication In Workspace ONE Access.  For Android, I found the article, "Breaking Down Workspace One's Android SSO", at mobile-jon.com very interesting.

A final step for getting Mobile SSO enabled is the configuration of conditional access policies on WS1 Access.  This involves simply assigning Mobile SSO as an authentication method or paring it up with device compliance policies.   Either way, conditional access policies are a very relevant topic and I'll be covering them next. 


Conditional Access Policies


Workspace ONE conditional access policies can be used to secure G suite access once a WS1 Access tenant has been configured as an identity provider within the Google admin console.  These policies define security requirements while taking into account a users context or device posture.  Circumstances like AD group membership, network range, device enrollment or posture drive the enforcement of authentication methods across different scenarios and uses cases.   The range of authentication methods to choose from can be quite broad in a mature WS1 deployment, enhancing G Suite security from both on-premises and cloud based solutions.  After a user has proven their identity to the satisfaction of these conditional access policies, they're granted a SAML assertion for access to G Suite services. 





















In a nutshell, conditional access policies map out different authentication requirements and fall bak methods required for G Suite access under various scenarios.  For instance, you might spell out that Win10 users leverage kerberos on-premises, while requiring AD credentials, certificates or 2FA for off-premises access.  Further, you may have different priorities and mechanism for iOS, Androids or Macs and can configure policies accordingly.  Below is a sample policy configured for a single app in my lab. 

















For a more extensive overview of conditional access policies, check out this tutorial, part of a 3 part series on WS1 Access in healthcare.

While a G Suite deployment stands to gain from the entire range of WS1 authentication methods available, Mobile SSO is particularly relevant.   Along with offering convenience for users it also provides a way of mandating device enrollment for G Suite access.  We can further extend this functionality by leveraging device compliance policies to take into consideration the security posture of an underlying device someone is trying to consume G Suite from.  In this manner, access is not only predicated on enrollment, but also device posture in regard to security concerns such as encryption status or OS version. 















We're essentially taking conditional access policies and juicing them with privileged information gained through device enrollment in WS1 UEM.  What constitutes compliance or non-compliance is configured on the WS1 UEM side of the house through device compliance policies.  The various attributes that inform these compliance polices vary from platform to platform.  Below is an example of the options for iOS.  

















This fusion of identity and MDM marks a highpoint of WS1, an innovation embraced and well received by most customers.  Fortunately, we can extend this device insight into other 3rd party IDPs like Okta, ADFS and Ping, a feature that's often referred to as device trust.      



Device Trust And 3rd Party IDPs


Conditional access based on device compliance has been a marquee feature of the WS1 suite for some time now.  Fortunately this capability can be extended to 3rd party IDPs by daisy chaining them with WS1 Access tenants.  The WS1 Access tenant, through it's built-in integration with WS1 UEM, can lend device insight to your 3rd party IDP's policies, a capability usually referred to as, "device trust."  An excellent example is the integration offered for WS1 and Okta.  After establishing WS1 Access as a trusted IDP for Okta,  Okta's routing rules can be informed by device posture information known through WS1 UEM.   The details of this integration can be found in the document entitled, "Integrating VMware Workspace ONE With Okta."  


















While Okta in particular offers some compelling enhancements for WS1 integrations, as far as basic functionality goes, this device trust capability is something offered to 3rd party IDPs across the board.  For example, similar to the Okta integration, VMware offers guidance for an integration between ADFS and WS1 Access in a document entitled, "Integrating VMware Workspace ONE Access With Active Directory Federation Services."  


This device trust option generally available for all 3rd party IDPs provides VMware customers flexibility and an easier path forward for WS1 adoption.  You don't have to rip and replace an IDP you may have already invested time, money and processes into.  Instead you can simply enhance it with device trust, fortifying what you already have in place with minimal disruption.  In the case of a G Suite deployment, you can continue to have desktops or laptops leverage ADFS or Okta, but then beef up security for mobile iOS and Android use cases.  A next step could be extending device trust to Win10 and MacOS through modern management.  From there you could even begin a transition to a zero trust model.  So, iOS and Android today, modern management use cases tomorrow, and then complete zero trust further years out.  Along the way, you could eventually migrate away from your 3rd party IDP or continue down this federated path indefinitely. 


WS1 Intelligence 


So far, the focus of this post has been on mature components of the WS1 suite.  For a more innovative approach to securing G Suite we can introduce risk scores and advanced automation from WS1 Intelligence.   

Risk scores generated by WS1 intelligence can further enhance conditional access policies.  So far we've talked about using conditional access policies to adjust authentication requirements based on device and identity context.  With WS1 Intelligence Risk scores we can add a 3rd dimension to this model, informing conditional access policies with advanced analytics and machine learning from WS1 Intelligence. 
























These risk scores are automatically generated by WS1 Intelligence based on users behavior. They take into consideration actions like delaying critical updates or disabling firewalls and antivirus. They're also impacted by Carbon Black events.   Regularly updated and maintained for each of your users, risk scores are leveraged by conditional access policies to judiciously right size and enforce authentication requirements.
Along with informing our conditional access policies, risk scores can be used to drive WS1 Intelligence's automation engine.  For instance, based off risk scores we can automate actions like enterprise wipes or app removal through WS1 UEM.  Or, on the less negative side of things, we can automate remediation of devices through other WS1 UEM functionality like the assignment of profiles.  

However, automated responses can extend even further through WS1 Intelligence.   Using custom connectors we can integrate with any 3rd party solutions that support REST APIs.  In a nutshell, if you can make it happen with a single request within Postman, you can automate it in WS1 Intelligence.  This opens up a whole world of opportunities. Not only can you execute actions within UEM, but you can create a ticket within ServiceNow or send a message through Teams or Slack.  All this automation can be driven through risk scores or triggered by events detected through the advanced reporting capabilities of WS1 Intelligence.  For more info on automation through REST APIs and WS1 Intelligence, check out this article, "Workspace ONE Intelligence Custom Connector Samples."


G Suite Specific Considerations


The last leg of this post will focus on the G Suite specific considerations of the design.  While WS1 capabilities discussed so far are applicable to a wide range or applications, there's definitely some G Suite specifics and challenges worth noting.  


Pushing Out Email Profiles To Mobile Devices



Traditionally ActiveSync, or Google Sync for Gmail, has been the mechanism of choice for pushing out email configs through WS1 UEM. However, with a shift to modern auth ActiveSync profiles are no longer an option.  By default, when initially configuring email in a modern auth scenario, users will have to navigate wizards to get their email configured.  This will involve launching the email client, selecting an email service, entering in an email addresses and providing authentication.   Android and iOS offer different options to facilitate this process, each with their own caveats and varying degrees of success. For iOS, it’s the relatively new, “Google Account,” payload. For Android there’s a special EMM Registration option for WS1 UEM leveraging a managed Google domain.  

Email Config For iOS


The Google Account iOS payload offers a way to simplify access to Gmail from the native iOS mail client. It provides a mechanism for pre-configuring a user’s G Suite account for use by the native client so that the user need only authenticate successfully to complete the configuration.





















If a user is able to follow some basic instructions, the process is fairly convenient and they don't have to select an email service or punch in their email address.  The main requirement is that upon the first launch of their native client, undeterred by an initial error message, they click on a, "details," hyperlink and follow the prompts.  If they do that, they can have their profile configured pretty easily, especially if Mobile SSO for iOS is in place to authenticate on behalf of the user.  Here's a demo of the what the process looks like: 


While this Google Account payload solution for email configuration isn’t completely on par with the convenance of an ActiveSync profile, it certainly offers a worthy alternative. ActiveSync, to say the least, is a bit long in the tooth. It was scheduled for deprecation October of this year, along with Google Sync, though a temporary reprieve was issued by Microsoft and Google due to challenges of Covid-19. That said, the writings on the wall: the future is not with ActiveSync and folks need to get off of it. Using the Google Account payload with modern auth provides a path forward. 

Unfortunately, while the Google Account payload helps with the native iOS client, it doesn’t assist with the Gmail Mobile App on iOS.  When first running the Gmail mobile client on iOS the user will have to select an email service, then punch in their email address. They'll then get redirected to WS1 Access, at which point Mobile SSO for iOS can take the wheel. It's not a horrible experience, just not on par with the connivence of an ActiveSync configured profile. 

Email Config For Android 


While configuration for the Gmail mobile app on iOS is a challenge, on Android there's a very compelling option.  If Workspace ONE is registered as the Android EMM with a managed Google domain, access to Gmail on your Android device is automated and fluid. When a device is registered the users G Suite credentials are associated with the Work Profile and access through Gmail is a snap.   Here's a demo:


There is one major caveat though.  While this offers really simplified access to G Suite mobile apps, it circumvents WS1 Access entirely, preventing the use of conditional access policies for G Suite mobile apps on Android.  So there's a trade off.   In exchange for simplified access you loose conditional access policies for G Suite mobile apps on Android.   However, you're still meeting the bare requirement of UEM enrollment.  This may or may not be an acceptable trade-off depending on your use cases and priorities.  


Token Revocation 


A real world G Suite challenge I recently observed has to do with token revocation on unenrolled devices.  Again, we have a situation where iOS devices present a challenge not experienced on Android. On iOS, after an enterprise wipe the G Suite token is still active and will continue to allow access to email until it's expired.   For most folks, this contradicts the expected behavior of having G Suite access completely  removed from an enterprise wipe.  On Android the challenge is completely circumvented by the default behavior of Work Profiles, but for iOS additional steps are required.

Fortunately, there's a work around available using the old Google Sync MEM configuration.  By creating a MEM configuration but not actually pushing out an ActiveSync profile we can leverage the token revocation feature traditionally used with Google Sync MEM management, while avoiding the pitfalls of ActiveSync.  Essentially it involves going through the motions of a traditional Google Sync configuration, but not actually pushing out the ActiveSync profile.   It's a clever way of harvesting this desirable token revocation feature that's traditionally paired with Google Sync while progressing to the use of modern auth. 


















With token revocation enabled, when there's an enterprise wipe the user's token will be removed from all devices.   To continue using G Suite the user's will have to re-authenticate on a remaining device or re-enroll a device into WS1 UEM.   Here's a demo of what happens to email access when a device is unenrolled and this token revocation feature is enabled. 


Overall, I'd say it's a nifty, though non-intuitive, hack for security conscious folks to tap into.  It might not seem significant at first glance, but if you're knee deep in a G Suite deployment with WS1, it's highly relevant.



DLP Considerations


With mobile applications like Google Drive in the mix, DLP is of pressing concern with a G Suite deployment.   While G Suite offers some advanced DLP capabilities through license enhancements, there's some DLP capabilities that WS1 UEM offers out of the box for any application it delivers.  For iOS, there's the ability to prevent the exchange of data with non-managed apps on the device.  While this might not be as granular as folks want, it is something and at least limits access to the data to other applications managed by UEM.  























With Android, once again, through Work Profiles, we have clearer cut delineation between work and personal worlds.   You can fine tune the details of the delineation through the restrictions profile for Android.  























Again, G Suite does offer it's own DLP functionality with additional licensing.  I've reviewed these built in capabilities of WS1 UEM just to add some context. 


BeyondCorp Alliance


An alternative solution that's currently baking will involve a direct integration option between G Suite and Workspace ONE UEM, without WS1 Access.  This has been recently discussed in the blog post, "Democratizing Zero Trust With An Expanded BeyondCorp Alliance."   I'm not fully aware of all the benefits this model will offer beyond the SAML integration covered in this post, but for those who are looking to exclusively protect G Suite it will offer an alternative.   While I'm not certainly when this option will be available, I'm certainly looking forward to seeing what it has to offer.  If nothing else, it could offer a simpler path forward for G Suite adoption when a customer doesn't have WS1 Access already in place. 


Conclusion



It was an absolute blast helping design this solution for a customer.   I haven't had a lot of exposure supporting G Suite, so watching it's deployment secured by traditional WS1 capabilities was certainly a sight to behold.  Again, these are processes and capabilities that WS1 can offer any SAML based solution.  It just so happens that, in this case, the SAML application was the incredibly impressive and feature rich G Suite solution.  Further, while this current deployment model satisfied a real and immediate need, it also laid the ground for the customer's future cloud adoption.  Typically, as folks of the vSphere generation, when we visualize cloud adoption we think of sucking VM's up in the cloud.  However, practically speaking the path of lease resistance is just purchasing services from SaaS vendors instead.  Well, with WS1 infrastructure in place, securely pivoting to these services is a lot simpler.  

No comments:

Post a Comment