Not drawn to scale #BYOD

Posted via email from Pre(posterous)

The case for & against embedded browsers for native client authentication

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 Password1 and is not one I have remembered. Consequently, to authenticate in this window, I have to go to that default browser and manually retrieve my Ping password from its store. Not a huge effort, and one that happens only once (or at most infrequently) but still less than optimal.

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?

Use case - Account linking

Existing customer links their Facebook identity to account - allowing for personalization, social marketing, and maybe login (with other authn factors?)

Posted via email from Pre(posterous)

Use case - sitting on couch

Ol skool - the family watching TV in the living room. Entitlements are based purely on the subcription

Posted via email from Pre(posterous)

Use case - social 'introduction'

In this scenario, the telco ascribes some initial set of entitlements (view a customized TV lineup based on user profile & location) to a potential customer based on an identity held by some social provider like Facebook etc.

The likely goal for the telco is to convert this potential customer into a real (paying) one.

Posted via email from Pre(posterous)

Use case - TV Everywhere

Alternatively, a customer of a different telco viewing content hosted by *this* telco  based on their subscription at the first - this the TV Everywhere premise. Note that the user has entitlements (as specified by the asserting telco) but no 'account'.

Posted via email from Pre(posterous)

Use case - road warrior

On top of that basic model, we can overlay particular use cases.

For instance, shown here is the scenario of a telco customer viewing their subscribed TV content from a hotel room whilst on a business trip.

Posted via email from Pre(posterous)

Use case - Road Warrior

On top of the basic model, we can overlay particular use cases.

For instance, shown here is a telco customer accessing their subscribed TV channels from a hotel room whilst on a business trip.

Posted via email from Pre(posterous)

Basic telco identity model

Users with identities (telco issued or not) use devices (telco bound or not) on networks (telco owned or not) to access applications (telco hosted or not).

Posted via email from Pre(posterous)

New line of greeting cards

Posted via email from Pre(posterous)

An Identity standards-based Model for Mobile Application Security

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.

Actors

First, who are the actors.

•  Enterprise – wants to control employee access to relevant business applications & corresponding data.  Does NOT want the corresponding security controls to overly interfere with employee’s ability to do work. The enterprise holds the authoritative identity for a given employee in AD or equivalent.
• 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.

The fundamental interaction is between the native applications ( labelled as 'SaaS1' and 'SaaS2') and their corresponding cloud. The challenge is to ensure that that the employee be able to use those applications in order to do their job and that those interactions are secure (authenticated, confidential, etc). The MAM agent on the device, driven by policy from its own corresponding Cloud, will enforce security policies.

Goals

At the highest level, I believe the enterprise has the following goals for mobile - it wants to ensure that

1. Valid employees can access the applications (and associated data) relevant to their role from their device and so be productive & content.
2. 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.
3. 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

1. only valid employees can access applications & data
2. valid employees can only access applications relevant to their enterprise role
3. when a valid employee becomes an invalid ex-employee, their access is terminated
4. any data delivered down to device of valid employee is protected both in transit and in device storage
5. 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

1. Manage (create, edit, delete etc) identities for its employees at both the MAM & various SaaS providers so that
2. 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
3. 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.

New line of greeting cards

Posted via email from Pre(posterous)

New line of greeting cards

Posted via email from Pre(posterous)

New line of greeting cards

Posted via email from Pre(posterous)

New line of greeting cards

Posted via email from Pre(posterous)