Monday, November 26, 2012
Box makes available a very slick desktop sync agent. In addition to a password based authentication mechanism (relevant to consumers), the agent also supports SSO for enterprise customer employees.
Disclaimer - Box uses Ping software to make the SSO happen.
Once installed, I need to connect it to my enterprise identity.
Below is the login UI.
On clicking on the 'Use Single Sign On' link, the screen toggles to eliminate the password form field. (and every password form field eliminated means that both a) a kitten is saved and b) the terrorists lose)
When I clock on 'Continue' on the above, the Box agent opens a browser window, loading a login page hosted by Ping (my enterprise). As soon as I authenticate to this page, Ping will send a SAML assertion attesting to my identity back to Box, for it to then accept as proof of my identity rather than via a password. Based on this authentication Box will send a (different) token down to the agent, this then used on API calls against the Box endpoints.
But, because the browser in which I am asked to authenticate to Ping is embedded within the agent (ie its not my default desktop browser), my Ping AD password (which I've stored in the default browser) is not available.
So I get an empty login form to fill.
My AD password is an incredibly long, complex, and random string
If the Box agent had instead opened the login page in my default browser, the sequence would have been a bit smoother. The downside (and the reason why I expect Box chose the model they did) is that the parameter passing between the default browser and the Box agent (necessary to deliver the second token to that agent for use on API calls) is more complicated than when the browser is embedded. For mobile OSs, use of a custom scheme URL gets you around this. Is there nothing comparable on desktop OSs?
Saturday, November 24, 2012
Friday, November 23, 2012
The likely goal for the telco is to convert this potential customer into a real (paying) one.
Monday, November 19, 2012
What are the identity requirements for securing employees access to business applications on mobile devices? What identity standards are relevant?
I’ll present a model for the above in this and subsequent posts.
At its most basic, the model proposes using 3 identity standards (SAML, OAuth, & SCIM) between the enterprise and the MAM (Mobile Application Management) & SaaS Providers – thereby allowing the enterprise to extend it’s purview out to the MAM (and subsequently) the SaaS Clouds.
Caveat - today’s MAM solutions do not (AFAIK) follow this model. But there are indications (from discussions we at Ping Identity are having with them) that some providers see the value.
First, who are the actors.
- MAM Provider - enforces enterprise security policy with respect to how employees use devices to access business applications . Comprised of
- Cloud endpoints, behind which sit the MAM policy (and maybe business apps) to be pushed down to the device installed agent
- Device installed agent, enforces the MAM policy and so keeps business data on the device protected & sandboxed
- SaaS Applications – offers up some service to enterprise employees. Comprised of
- Cloud endpoints, behind which sit the application data – accessed either via a web interface or via a native application. Note: although labelled here as ‘cloud’, the principle is the same for on-prem endpoints, ie for custom enterprise native apps interacting with on-prem endpoints).
- Native versions, OS native applications that interact with the corresponding cloud endpoints to pull down application data, for local display & manipulation
- Web versions, accessed via device browser (while the relative importance of web & native may change in near future with HTML5, both are likely to co-exist. So our model must support both.)
Graphically, see below. The native applications & MAM agent are installed on the device (as well as the browser), they interact with their corresponding server endpoints – these interactions acting under the control of the enterprise via the access control, encryption, etc mechanisms provided by the MAM solution.
At the highest level, I believe the enterprise has the following goals for mobile - it wants to ensure that
- Valid employees can access the applications (and associated data) relevant to their role from their device and so be productive & content.
- Nobody else (neither family, colleagues borrowing the phone, the well-meaning stranger who finds the phone in a cab, or a malicious hacker) can access those applications (and associated data) if they get their hands on the device.
- The controls of #2 do not inappropriately impact the employee’s personal applications & data on the device , ie respect the employee’s privacy.
Note: I contend that the above (even the last) are valid whether the device is owned by the enterprise (a COPE model) or the employee (BYOD). Consequently, ownership is mostly a red herring (or at least an orthogonal issue) when thinking about securing mobile applications.
The first goal above is satisfied by giving employees convenient access into both the:
1. Web version of the business applications
2. Native versions of the business applications
Of course, ultimately the enterprise cares less about employee convenience than about productivity. But there is of course a correlation between the two – if you make it convenient for employees to access business applications, then you don’t prevent them from using those applications to sell widgets, review iPads, create Venn diagrams, or whatever it is they do for you.
The second goal can be satisfied by ensuring that the above access to applications & data, while convenient, is also secure, ie
- only valid employees can access applications & data
- valid employees can only access applications relevant to their enterprise role
- when a valid employee becomes an invalid ex-employee, their access is terminated
- any data delivered down to device of valid employee is protected both in transit and in device storage
- when a valid employee becomes an invalid ex-employee, any data stored on device is removed (or equivalently made inaccessible)
The third goal above can be satisfied by isolating the employee’s personal applications & data from the security & policy controls of the enterprise – fundamentally to leave alone anything that is not under the enterprises legitimate authority – like Angry Bird high scores and wedding pics. Whether BYOD or COPE, it behooves the enterprise to respect the employee's privacy.
In the next post , I’ll show how the enterprise can use identity standards like SCIM, OAuth, & SAML to meet the above requirements of convenience, security & privacy – specifically how the enterprise can
- Manage (create, edit, delete etc) identities for its employees at both the MAM & various SaaS providers so that
- Those employees can access the SaaS applications relevant to their job , and do so in a manner compliant with enterprise policy (as enforced by the MAM) and importantly
- Not require the employee be issued (and so be forced to remember) passwords for all these various services but instead enable access to applications via Single Sign On for both web & native applications.
Tieing back to the diagram, as drawn above there is significant 'whitespace' between the enterprise & the MAM (where IT wants to define security policies) and the SaaS clouds (where employees need to be able to access application functionality). Employee's have an identity in the on-prem AD, but the stuff they need to do is out in the cloud. How do you bridge that gap? I'll show how in the next post.