Anywhere Workspace

Solving iOS Shared Device App Logout with Workspace ONE Intelligence Automations

Introduction

As a member of the Consulting organization of VMware, I have seen many challenges balancing user experience and security. Often these topics are opposing forces.  One recent challenge common to many Healthcare organizations, or Front-line use cases, is how to utilize an iOS device in a shared capacity.  Many organizations love iOS for its easy-to-use user interface, and friendly navigation capabilities. It is common to have a one-to-many device to user ratio, to accommodate shift users.  These needs from budgeting and logistics present challenges around security and data leakage from user to user. This blog will dive into this topic and offer a solution to meet some of the challenges.

iOS shared devices and applications

A shared iOS devices is a popular way to use hardware as cost effectively as possible. Apple doesn’t provide a method to manage multiple users on iOS phones.  Workspace ONE steps up and the Intelligent Hub allows you to sign in and out of the device with your corporate identity (and your favorite Identity Provider). It can then leverage this identity to personalize the device to your role and specific entitlements, and importantly use Mobile SSO with Workspace ONE Access, to provide corporate credentials via a certificate to offer no touch sign on to any modern authenticated application.  However, as iOS has no native shared model, there isn’t an effective way to clear user information from 3rd party applications and the keychain.  Thus, when a user signs out of the device, using Intelligent Hub, any non-VMware application would remain signed in.  This you can see presents a large data loss challenge.  Traditionally for many organizations this was managed by carefully curating the allowed applications, for instance using Workspace ONE Web instead of Safari (so we can clear browser history, cookies, etc.), or applications with very short token lifetime (see a previous blog I was part of on how we managed this with Epic applications).

Vocera Vina – The case to create a closed loop

Enter my Healthcare customer, and their mission critical application, Vocera Vina. Vina offers federation using the SAML protocol to any SAML2 compliant IdP.  This customer’s primary IdP is Okta, a well known leader in the IAM space.  In a previous engagement I worked with their head of security and IAM, to federate Workspace ONE Access with Okta, rationalized the applications security posture to Low, Medium, and High classifications. We then put Workspace ONE Access as the primary Identity Provider, in the routing rules, to allow Workspace ONE’s Mobile SSO feature (certificate auth on mobile) to authenticate managed devices quickly.  All applications initial authentication were sent to Workspace ONE for Mobile SSO and Device Compliance check. The Vina app classification allowed the user to have a no-touch SSO experience with Mobile SSO without additional MFA prompts.  So we had the security and user experience for the Sign On piece of modern authentication but we were missing the Sign Out piece.  Thus once a nurse checked-in the device (signed out of Intelligent Hub) the Vocera Vina app would remain logged in.  This presented security and regulatory challenges. 

Our customer had a great relationship with the Vocera vendor. Our three teams had a virtual whiteboarding session on how best to handle the situation, without starting from the ground up, and achievable in a short timeframe.  We settled on an API.  The Vocera admin console already has a function to log off a user from the application, so we asked for an API to be built so Workspace ONE could trigger it when the user logs out of Hub.  Vocera saw this as a low effort way to accomplish the task and wasn’t vendor specific as other possibilities (app SDKs), and delivered the feature quickly.

Enter automations for Custom Connectors powered by Workspace ONE Intelligence

After Vocera delivered the capability to call an API to trigger an application log off, we needed a flexible way to trigger this using Workspace ONE suite. Workspace ONE Intelligence offers Automations, typically used to call UEM actions such as to remediate a missing patch, or application, also offers ‘Custom Connectors’ which allow an API connection to a 3rd party.  There are quite a few websites and blogs which highlight how to create a Custom Connector.

The important bit to understand is the Workspace ONE platform has a way to communicate to external sources.  Before Custom Connectors Workspace ONE platform was primarily a source of data itself, where systems would poll Workspace ONE UEM for information. With Workspace ONE Intelligence and Custom Connectors, you can send any data stored from the platform to any other software that can understand and ingest data. This new capability opens the doors to many powerful integrations, such as the one highlighted in this blog.  To give you an idea how the workflow works please see the picture.

Once an end user signs out of Hub, UEM is immediately notified, and this data is fed into Workspace ONE Intelligence.  An automation triggers on the username switching back to the ‘staging’ user of the device, which calls a Custom Connector. This Custom Connector calls the /vocera/SAML/webLogout endpoint hosted on the Vocera server with a POST with the previous users username in the body.  This workflow takes just seconds, which tells the mobile application there is no valid session anymore. Thus freeing up the application to be signed in by the next Nurse once they log into the device

Closing

With the Workspace ONE platform, it has morphed into something much greater than the sum of its parts.  With talented IT professionals at the helm we can sincerely move the needle for user experience, security, and glue the various IT systems together.  Learn how VMware Professional Services for Anywhere Workspace can improve mobile operations for healthcare workers. 

Vocera and Vina are trademarks of Vocera Communications.