Using Radiant Logic RadiantOne VDS as a Mobile Gateway

With the growth of mobile applications, companies are faced with the challenge of creating a secure mechanism to integrate these applications into their overall infrastructure. Things like the centralized management of secure authentication, single sign-on across applications, session management, creation of a federated identity platform and application level privileges create a overly complicated architecture that is susceptible to security breaches. This is further complicated by the industry shift towards cloud-based applications. Luckily the same tool that companies are leveraging for identity federation can be easily enhanced to provide a simplified platform for securing mobile applications. Radiant Logic’s RadiantOne Virtual Directory Server (VDS) provides a platform for not only implementing these capabilities, but also for creating a unified hub for access to and routing of identity and other data in a secure, highly available and high performance framework. The ability to inject logic into the virtualization process and create a cache of relevant data allows companies to easily adapt their installation and extend it to act as a mobile gateway.

At a high level the VDS-based mobile gateway provides:

  • A standard interface for authenticating users regardless of credential type
  • The ability to leverage the existing credentials for users instead of having to create another identity and identity repository
  • Centralized hub of correlated identities coming from any number of sources across the environment
  • A common gateway for providing enriched user data with a common schema for user attributes across a user’s federated identity and other related data
  • Session management with the ability to provide single sign-on across mobile applications, enforce timeouts and enforce common logoff
  • User-specific security controls for access to data elements
  • The ability to provision user identities and user attributes into the identity environment
  • Secure identity firewall for access to internal identity information
  • Single sign-on into CA SiteMinder and Ping Identity PingFederate secured environments

Since these applications operate on an insecure and easy to lose platform, careful security principles must be considered. Creation of a secure transport protocol and means to limit the amount of data required to be stored locally in the mobile application better ensures corporate data is secured. Also, a firewall must be established for access to internal data instead of having to expose internal sources directly to the Internet. Leveraging industry standards such as DSML, SPML and open cookies limits the need to develop proprietary, non-peer reviewed mechanisms to authenticate users and access data.

A mobile gateway can be deployed using the approach in the following diagram:

Federated identity information is correlated within the VDS Mobile Gateway and exposed through a VDS identity firewall. An Identity Based Encryption key server is used to encrypt the transport of data between the gateway and the mobile client. To simplify client-side development a quick start SDK can be provided for quickly integrating applications.

The VDS Mobile Gateway is logically comprised of the following three high-level pieces:

  1. DSML/SPML interface allowing the application to identify itself, set sessions and retrieve sessions from the mobile gateway.
  2. VDS is used for authenticating users, correlating user information and managing session data.
  3. Identity Based Encryption (IBE) interface to secure information between applications. This allows the mobile gateway to encrypt data for the receiving application without knowing its public key. It can make the data accessible for only a specific period of time and applications can easily be “unauthorized” from the network.

At a high level, here is the general flow for accessing the mobile gateway:

  1. User information across the federated network is joined and correlated in VDS and cached for high performance.
  2. On startup the application registers with the Virtual Directory to determine the authentication method over SSL.
  3. When a user authenticates to the application, the credentials are sent to the mobile gateway over SSL.
  4. The VDS mobile gateway authenticates the credentials and (if valid) creates an OpenToken or Open-format based session token containing the user’s session information.
  5. VDS creates a unique session identifier and stores the session token and session identifier as part of the user’s extended profile.
  6. VDS requests an encryption key for the user’s session from the IBE Master Key Server.
  7. VDS returns the session token, session identifier and client specific encryption key based upon the session identifier to the application.
  8. Additional DSML requests to access information use the session identifier as the user ID and the session token as the password. ACI’s on the attributes secure access to user and attribute data.
  9. VDS takes the session token, validates it against the cached version and updates it as needed.
  10. Data is encrypted for the session using the application client’s assigned encryption key.
  11. By passing the session identifier and session token to other applications, those applications can connect to the gateway without re-challenging the user for credentials to retrieve data and their client associated encryption key.
  12. Since the session token is created as an OpenToken or Open-format cookie, the token can also be passed to SiteMinder or PingIdentity secured sites as a cookie for SSO into those applications.
  13. Additional data can be provisioned through the mobile gateway using SPML (or DSML if possible) to send data to VDS. VDS then updates the data in the underlying user repository.
  14. Logging out removes the session data from the user’s extended profile and invalidates the client’s encryption key. This can also be done on an idle or max session timeout.

While VDS provides out-of-the-box services for identity virtualization, attribute security, DSML and SPML, the system needs to be extended. This is easily achieved using interception scripts to plug in the session and token creation, validation of session data, retrieval of encryption keys and logout of users.

Here are a few of the benefits of this approach:

  • VDS unifies identities across the application ecosystem and applies business logic to correlate the sessions as required without having to code this logic into the application.
  • The mobile gateway capabilities are easily achievable by leveraging the integration interfaces available in VDS today.
  • Access to information is virtualized and secured from direct access.
  • Applications do not need to directly authenticate users or store sensitive data locally.
  • Minimizes the propagation of session information to only approved applications with a controllable set of access and encryption policies.
  • Provides the ability to build information policies that specify session usage including validity period, application access, etc. which increases security and lessens session proliferation.

All of this can be done using the same principles used to build out VDS implementations today. Companies deploying VDS or with existing implementations can extend the capabilities provided with their core installation with this functionality.

Breaking this flow down, VDS Mobile Gateway authentication and single sign-on is represented by the following diagram (NOTE: for simplicity the diagram assumes that credentials and session information is valid):

  1. The mobile application sends an initial DSML request to an application specific view in VDS to retrieve the authentication type.
  2. The request is proxied by the Identity Firewall to the VDS Mobile Gateway.
  3. VDS responds with the type of authentication, which is proxied by the Identity Firewall back to the client application.
  4. The client application challenges the user for credentials, collects the credentials and submits them to the Identity Firewall using DSML over SSL.
  5. The Identity Firewall proxies the request back to the Mobile Gateway.
  6. The VDS Mobile Gateway validates the credentials.
  7. Using an interception script, VDS creates a session identifier and session token. The session token contains relevant user information such as user attributes, session timeouts and session key.
  8. Using an interception script, the VDS Mobile Gateway requests an encryption key from the Identity-Based Encryption (IBE) master key server.
  9. The IBE server creates the encryption key identity based upon the user session identity and session key (from the session token) and returns the key to VDS.
  10. VDS bundles the session data as user attributes and returns the values in the DSML response.
  11. The Identity Firewall proxies the request back to the mobile application.
  12. The client caches the session and key data for future requests.
  13. Additional requests made to the server and authenticated using the session identifier as the user ID and the session token as the password. These values can be passed to other applications on the device or as part of an HTML request to a SiteMinder or PingIdentity protected site.
  14. Requests or data sent to the VDS Mobile Gate (and proxied by the Identity Firewall) are encrypted using the mobile gateway’s key and response data is encrypted using the client session identifier and key pair.
  15. An interception script validates the session information passed in as the credentials for the request.

The following common logoff flow diagram highlights the process for ending the user’s session:

  1. The mobile application sends a logout request using DSML with the users session identifier and token.
  2. The request is proxied by the Identity Firewall to the VDS Mobile Gateway.
  3. Using an interception script VDS removes the session identifier and token from the user’s extended profile.
  4. Using an interception script VDS notifies the IBE Master Key Server to destroy the encryption key associated for that user’s session identifier and session key pair.
  5. The logout success response is return as an attribute in the DSML response and the client should clear any locally cached data. Access to local information is no longer possible since the leveraged encryption key is no longer valid.
  6. While subsequent requests may have the user’s session identifier and token, the VDS Mobile Gateway no longer considers them valid and the requests are rejected.

This solution can be delivered through an existing on-premise VDS implementation or through a cloud-based identity service. Additionally, the on-premise and cloud solutions can easily be combined through the virtual directory’s ability to join data across systems. Basing this on an open standard ensures that customers can leverage this investment not only for mobile applications, but also for any other clients that want to leverage the service. The client SDK speeds implementation and abstracts local logic and things like proactive logoff can be achieved by using a heartbeat or ping back to the mobile gateway.

Using a VDS-based virtual infrastructure makes creation of a mobile gateway readily consumables as a way to provide services on a per application or consumer basis and lends itself to an out-of-the-box multi-tenanted architecture. Since the virtual directory can process both application and user data, you can simply create a view into the information by individual/group/organization etc., without having to specifically code this as a multi-tenanted solution. Since authentication processing is performed by the VDS Mobile Gateway, any authentication scheme can be supported (user ID/password, certificate, oAuth, token, etc.) without the client having to implement authentication logic.

Additional functionality can be added by giving identities to the applications themselves. Using oAuth, the user can authorize and application to manage their session. The application then leverages that credential in addition to any user session data when making requests. This has the advantage of better securing the initial request to retrieve the authentication mechanism, allowing the user to remove authorization for applications themselves and create rules for which applications can share session data. An application identity or avatar can also be used as a way to access session data stored in VDS itself instead of managing it at the client level. Since the application has a controllable identity, the mobile gateway can manage access the same as any user-based identity. This identity can be used as another key for encryption of data to ensure that the application in addition to the user is able to access the data.

Depending on the security level of the application, a cached credential can be leveraged for offline use with a formal validation or authentication process once the device is back online.