WorxWeb is the mobile web browser, deployed as part of your XenMobile deployment. In a manner similar to WorxMail (the secure mobile mail client), WorxWeb provides seamless and secure access to your entire set of corporate HTTP / HTTPS resources.
WorxWeb is a great example of our MDX technology. With MDX, we take a native mobile application, wrap it with our MDX technology, and provide a layer that:
- Enforces MDX policies for app level compliance
- Monitors and controls inter-app access, based on policies defined by the admin
- Monitors and controls Network access – MicroVPN – for access to corporate resources
One of the coolest things about WorxWeb, is its ability to Single Sign On users into corporate resources. So every time you access your internal company portal, via WorxWeb, you don’t need to punch in your LDAP credentials again. WorxWeb manages that for you. Or for sake of technical accuracy – NetScaler manages that for you.
It’s a conscious choice, for sake of greater security, that we do not cache user’s credentials on the end point (by default – we do allow policy based caching, if you choose to). So, if the credentials are not available on the end point, how does this SSO work?
That’s the NetScaler magic.
Initially, when you launch any MDX app, WorxHome ensures that you have a valid MicroVPN session available with NetScaler. As part of setting this up, the user would need to provide his/her LDAP credentials, assuming LDAP is one of the factors configured for authenticating the user on NetScaler. Now as part of this LDAP authentication, NetScaler is able to access and save the user’s credentials for later use, for seamless SSO on behalf of the user.
So when a user opens WorxWeb, and launches say an internal portal page, this is what happens in the background:
- Often the portal page will return a HTTP 401 error, indicating that user authorization is required to access the page.
- NetScaler is privy to this transaction, and on seeing a 401 returned, intercepts this and responds with user’s credentials to the web server.
- If user credentials play out fine, and the web server accepts this transaction, it will return the fetched page, along with a HTTP 200 OK status.
- This page is then returned to WorxWeb on the end user device. In essence, we just performed a Single Sign On.
Note that the attempted Single Sign On, is dependent on the following things:
- Resource authentication credentials are same as one of the factors set up on NetScaler. Note that NetScaler’s capability of replaying user’s credentials is inherently linked to the assumption that NetScaler has access to these credentials. Now NetScaler never stores these credentials on the disk, in a matter similar to what a password vault might do. But as part of session creation on NetScaler, it does store the credentials used to sign in, as part of the user’s session context (safely encrypted). And if these credentials match the credentials required for resource access, theoretically we can achieve SSO.
- Above factor, is not enough to perform SSO. The other thing that matters is that NetScaler be able to see the 401 challenge. NetScaler’s ability to see a 401 is possible only if the session being bridged via NS, is not end to end SSL encrypted. Therefore a session that’s HTTPS, with the back end, may not be peeped into, and hence an attempt at SSO, not possible. Having said that, NetScaler is a smart appliance, and provides a possible workaround. NetScaler has multiple modes in which a client may interact with the NetScaler, in order to reach the actual backend resource. Two of those are:
- MicroVPN: Micro VPN is a full VPN tunnel, but specific to an application. In a Micro VPN, the most common communication protocol used in XenMobile, NetScaler suffers from the above limitation – lack of ability to peep inside a HTTPS session.
- SecureBrowse: In SecureBrowse mode, NetScaler breaks up the HTTPS session into two – client to NetScaler, and NetScaler to backend resource server. In this manner, NS has full visibility into all transactions between the client and server. Given this, NS is now in a position to peep inside and see a 401 in play. And whenever a 401 is seen, NS can replay user’s credentials to achieve SSO.
- There is a third factor that comes into play, which may decide NetScaler’s ability to SSO – Supported auth methods. Every 401 challenge lists the auth methods that can be used by the client to perform user authentication. Depending on the auth methods supported by the server, and auth profiles configured on NetScaler, it may or may not be able to provide SSO. Following SSO methods are supported on NetScaler:
- Basic HTTP Authentication: NetScaler performs this automatically, as long as SSO to web applications is enabled in the session profile.
- Digest HTTP Authentication: NetScaler performs this automatically, as long as SSO to web applications is enabled in the session profile.
- NTLM Authentication: NetScaler performs this automatically, as long as SSO to web applications is enabled in the session profile.
- Kerberos Impersonation: This requires configuration on NS, for Kerberos SSO. This is explained here.
- Kerberos Constrained Delegation: This requires configuration on NS, for Kerberos SSO. This is explained here.
- SAML Authentication: This requires configuration on NS, for SAML SSO as part of Traffic Policies. This is explained here.
- Form Fill Authentication: This requires configuration on NS, for Form based SSO as part of Traffic Policies. This is explained here.
XenMobile is a comprehensive Mobility Management solution, and power packed with tons of features. This article attempts to provide insights into, just one of these mechanisms.