Hello,
One of the most frequent questions I get about the Mobile API Gateway is how do we support Single Sign On. This is just one of many features MAG support but it deserves some extra attention with the explosion of app projects with our customers and their demand for optimized user experiences. In this post I will cover the basic capabilities of the MAG w.r.t. to SSO across different app types.
Fundamentally, the Mobile API Gateway and its Mobile SDK offer tooling for organizations that needs to mobilize their application assets. They do this for the benefits of increased productivity and being able to serve their customers better. In some cases they build apps for employees while in other cases they are building apps to increase the contact surface with customers and provide a better service through apps. The MAG helps by giving them freedom to choose between the app types while retaining a unified security model across these app types. So how is this achieved?
The solution include client-side libraries for iOS, Android and PhoneGap. These libraries can be used by enterprise developers to enable mutual trust between the client app and the backend service provider, to integrate the organization’s identity management infrastructure, and to simplify the process of secure client-side authentication and SSO. The API Gateway integrates to a slew of different enterprise identity systems, like CA Single Sign-On (aka SiteMinder). In addition, enterprises can use social login providers such as Salesforce, Google, LinkedIn and Facebook for authentication through the same SDK. This can then be augmented with geolocation policies for better protection while providing easy onboarding of users especially for the enterprises that build out apps for their customers. Regardless of the chosen user authentication mechanism the SDK helps establishing mutual trust between client apps and server which enables secure consumption of those backend APIs.
The client side architecture consists of a private keychain that is created for each enterprise application to store an access token and refresh token, and a shared keychain used by all applications from the same enterprise to store a trusted server certificate, a JWT identifying the user, and a private key and cert used for mutual authenticated SSL across all enterprise applications. The crux of this is the auto-provisioning feature. The client library in tandem with the MAG ensures that all token artifacts are deployed upon successful authentication. The device, app and user will participate in a registration handshake with the first API request which sets this up. The keychain is encrypted with a key consisting of both the device’s lock pass code and the device’s unique hardware ID. So far so - good tokens and certs are protected on device - what's next?
The client-side libraries then offer an API for application developers to do HTTP calls to server-side APIs, essentially auto-decorating the API requests to match the security policies on the APIs protected by Mobile API Gateway. Any calls using the libraries will ensure that a valid user and access tokens are available; if no valid access token a new is requested with JWT. If no valid user token, the user is asked to provide valid credentials through a customizable login dialog. The key is that these credentials are exchanged for user token that then is securely shared for all apps that are signed with the same developer key. All this through a "getResourceForPath" type of client lib API call. This process is entirely transparent to the user, beyond a single sign-on.
The 2.2 release has added support for SSO across not only native but also web apps - now spanning all types of apps; native, web and hybrid. This is important objective as enterprises already have invested in WebSSO technologies. Many of these organizations have attempted to build mobile apps with this and largely failed with a poor developer experience, poor user experience, and inadequate security. Because these are fundamentally web technologies and don’t take advantage of the native capabilities on the device they have ended up with a siloed approach where user login and security measures are all different - depending on which app type and on which device used. But, rather than throwing this away the question should be "how to leverage this infrastructure while improving the mobile capabilities". Acknowledging the success of WebSSO and SAML in the desktop browser SSO scenario helps understand what the solution must look like for mobile apps.
To address this - the MAG comes with a reference design app which will simplify access to enterprise apps and protected assets. While leveraging improvements in SDK and MAG the reference app visualizes all app assets as tiles in a single view. After having signed in, and MAG have ensured the right token artifacts are in place (per above), the user is presented with a grid of app icons (or "tiles"). Each icon represents a link to the enterprise app, be it a native or web app integrated with existing WebSSO infrastructure. This grid is described in a JSON structure that client lib is retrieving from a new MAG protected API. The MAG can be integrated to enterprise entitlement management solutions to serve a per-user app list but the default is static JSON. The client lib listen for and processes tap-events on tiles. It determines if the target is native or web and takes appropriate action to obtain the required tokens. For example, if the enterprise uses the Salesforce web app this can be configured to show up in the app tile grid. When the user tap on the SF icon the client library would request a SAML token for SF to be issued and return to client lib. The SAML token would either be issued by the existing WebSSO infrastructure or by MAG itself before passed back to client. The Mobile SSO app would then use this directly with SF to render the web app – automatically signed in – with a standard native security model. If the user now, tap another tile, targeting another native or web app, the user is already authenticated, but the SAML token process must still take place for the this target web app. This feature offers enterprises who are looking to mobilizing their app assets with a unique and valuable toolkit for doing so. They can optimize for security and user experience across app types.
One can argue that this could have been solved if the device OEMs, like Apple, Samsung and some others had a plugin model in the built-in browser. Now, that opens up a whole new set of problems, so one can assume good reasons for not doing it but they should address enterprise SSO between web apps and native.
I will cover additional SSO capabilities on offer in a follow-up post. This is likely including cross device session transfers and Samsung Knox SSO enablement with MAG.
Cheers
Leif