ConnectID

Elvis-like, the data has left the building

2013-06-12T11:43:00.001-04:00

Enterprises want to ensure that its business data is accessed only by those who have a valid right to do so, ie those that require access in order to do their jobs. When the business data is only ever stored on a server, behind a web page or an API, restricting such access is relatively easy. Authenticate the user sending the request for the data, check their roles, determine if the roles are such that the user has a justifiable need to get at the data and, if so, approve the request and send the data back to the requesting client. (When the identity store (where the roles are kept) is remote from the business data (as is the case when the data is held by some SaaS), the mechanisms (and standardized protocols) might differ, but the logic remains the same).

A client sends a request for the data - this request intercepted by some sort of enforcement mechanism (a Policy Enforcement Point (PEP) in the lingo). A co-located Policy Decision Point (PDP) determines which policy is relevant for the requested data, and interprets that policy to make a decision whether to grant the request or not. If the decision is 'yes', the data is served up back to the client (either as HTML or JSON depending on the nature of the client).

All good, but as soon as you allow the business data, once released by the server, to be stored by the requesting client beyond the original session, then the original access control check is no longer sufficient and must be supplemented. Despite the additional complexity, mobile native applications and enabling offline usage (the 'CEO sitting in seat 3B' use case) push the enterprise towards supporting this sort of client storage.

The Mobile Information Management (MIM) proposition is that the business data delivered down to the clients (the native applications) carries with it (implicitly or explicitly) the policies governing its access & usage - reminiscent of DRM. Before the data is delivered down to the mobile client, appropriate policy is bound to the data - the policy will stipulate what users and/or applications can access the data, what they can do with it, and restrictions on subsequent sharing. Once on the device, only if the policy stipulations are met will the data be made accessible to particular applications, and what they subsequently do with that data will also be accordingly constrained.

But merely attaching some rules to a document or powerpoint (PRISM anyone?) doesn't actually restrict access to that data. It would be a polite hacker that, seeing a rule forbidding her access, respected that rule. There needs to be a mechanism on the device comparable to the PEP in the diagram above to enforce the policy, ie prevent all data access unless the policy is met.

You also need something comparable to the PDP to read & interpret the policy associated with a given piece of data. But whereas in the above model, the policy decision was whether or not to release the data itself, in this case the data has already been released, it's already on the client after all. So what is the decision?

In MIM, the policy enforcement mechanism (the PEP that prevents unauthorized access) is appropriate encryption of the data, and the policy decision (made by the PDP determining what is authorized access) is whether or not to release a key that can be used to decrypt the data.

An abstract model is shown below

On the right is some piece of business data, encrypted to prevent just anybody who has access to the device on which it sits from being able to access the data. On the left is a decryption key that will decrypt the encrypted data and so make it accessible to application usage. For an application to be able to 'get at' the data, it will need to gain access to the decryption key.

Sitting between the two (the encrypted data and the corresponding decryption key) is the policy enforcement & decision infrastructure that ensures the two will 'meet' if and only if the policy is satisfied. Policy associated with the encrypted business data stipulates under which contexts the decryption key can be released, as well as additional constraints should that happen. Taken as input to the 'key release' decision are all the various current contexts, ie what app is trying to access the data, one behalf of which user, when, where etc.

If the policy decision is 'yes', then the PEP releases the decryption key to the application, along with additional constraints (read but no right, no sharing etc). Now armed with the decryption key, the application uses it to decrypt the data and does whatever it does.

The above is abstract, how to make it concrete? Specifically

how is the policy bound to data?
how & where is the data encrypted?
with which key?
how & from where is the decryption key obtained?
how are PEP & PDP roles distributed?

Next time I'll propose an architecture for the above that leverages

REST APIs
OAuth & OpenID Connect as mechanisms for authenticating & authorizing clients to such APIs

Discovery for IoT

2013-05-29T07:28:00.004-04:00

Premise is that the IoT would have us awash in services advertising us of their availability.

So, how to filter this sea down to something useful & manageable?

Via filters determined (mostly) by the context of everything else we have going on - what searches we've performed, what events are in our calendar, what we've recently bought, listened to etc etc.

Those services that meet the criteria are allowed to prompt us (via applications?) for interaction.

Identity, application models & the Internet of Things

2013-05-24T08:35:00.001-04:00

In a blog post entitled 'Mobile apps must die', Scott Jenson argues that the Internet of Things (and the associated implication of having to interact with all the 'things') will make the native application model impractical, and push application development back to the browser.

I buy the argument, will repeat some of it and will try to tease out some of the identity implications.

First, a bit of a recap of Scott's argument (or my interpretation at least)

Whereas on a desktop we might have had ~10 installed apps, on a phone or tablet we might have ~100. Users have to manage this list. It is trivially easy to install apps from the app stores. That’s great from the app developers PoV, it minimizes the pain of installation and so allows for Users to play and experiment. But from the Users PoV there is a price to be paid for easy experimenting – the application remains. SSO between these apps helps but the problem is bigger than just authentication.
Offline mode will become an antiquated concept as connectivity becomes ubiquitous. ‘CEO on a plane’ will disappear as an important use case when every plane has wifi. Consequently, the current advantage native has over browser models with respect to supporting offline via device storage will become less relevant.
As more and more objects become connected (IoT), the nature of mobile applications (through which we’ll interact with those objects) will have to change accordingly. When my fridge, dryer, furnace, air conditioner, microwave, and thermostat etc are all connected and desperately want to interact with me – do I want a unique app for each of them? And what about objects outside the house – coke machines, point-of-sale terminals, bus stops schedules, restaurant menus, gas pumps etc

So the Internet of things would push us to have 1000s of native applications on our devices, but that would place a completely unrealistic management burden on the User – installing, authenticating, sorting, updating, & deleting of applications when no longer needed etc.

The problem is that the current native application life-cycle looks like

Discover
Install
Authenticate
Use
Update
Remove

This sequence places a heavy burden on the user and is very static – not particularly applicable to a ‘Just in time’ model (as Scott puts it) where I might interact with an application once and never again.

Clearly this isn’t viable in an IoT world where we will constantly be presented with previously unseen connected objects. We’d spend our days installing apps and by the time we were ready to interact, the opportunity will have passed (somebody else would have grabbed the last Dr Pepper etc)

IoT demands an application interaction model that is far more dynamic, something like

Sense – my device must be constantly on the lookout for IoT connected objects and, based on rules I’ve defined, determine whether & how best to interact with them
Notify – based on rules I’ve defined, prompt me to know that I can now interact with the object
Authenticate – the object may need to know who I am, but this obviously has to be seamless from a UX PoV. (the object may have to be able to authenticate to me as well)
Use – I interact with the object. This can’t require an ‘install’, instead whatever unique application functionality must be downloaded and run in an existing app designed with this sort of flexibility – ie a web page running in a browser
Cleanup – as there was no install, there are no artifacts (except perhaps some state to simplify the next interaction) to be cleaned up, ie no uninstall

The Internet of Things would appear then to be pushing us towards a future where

The pendulum swings back to the browser (& so HTML5 comes into its own)
The importance of browser means Web SSO remains relevant
For Web SSO, SAML gives way to OIDC due to its support for Javascript-powered apps running in the browser and pulling data from APIs offered up by the 'things' (or network endpoints on their behalf)
SSO (in the sense of facilitating seamless user authentication to all the various IoT objects) is absolutely critical.

The last can be summarized as

IoT won't scale without SSO to the T.

Imagine I have a smart toaster that I want to interact with on my phone to determine if I need to empty the crumb tray (this needs to happen Science!!)

How

does the toaster advertise its presence to the phone?
is the user invited to interact with the toaster?
toaster data (crumb tray status etc) get sent to the toaster cloud for analysis
toaster data (crumb tray status etc) get sent to the phone for display

This diagram is a really rough attempt at a model

The toaster serves up crumb tray data (& some javascript) to the device browser. The javascript interacts with an OAuth Authorization Server (we can get the User consent at this point) and obtains an OAuth access token that represents the combination of toaster & User. The javascript then uses the access token to upload the data to an associated TAAPI (Toaster Analysis API) for analysis and then renders application UI to the user based on that analysis (eg ALERT - CRUMB TRAY DANGEROUSLY FULL).

The Quantified Self & Application Scale

2013-05-01T09:46:00.000-04:00

As part part of the self-quantification (QS) movement, there would appear to be a pairing of measuring device & associated application for every aspect of personal health - diet, weight, prescription medicine, fitness, blood, breathing, GI tract health, etc.

Devices measure the various X (some passively, some actively), and the associated application, once installed onto a phone or tablet, displays and analyzes the collected data for the user - presumably to help them make health decisions in the direction of longer life (and so longer duration customer for the application provider).

When each health aspect has its own device, and each device has its own native application - the user will necessarily bear the burden of installing, managing, and authenticating each native application.

That may be an acceptable burden for somebody with 2-3 separate devices (and so 2-3 native applications). But what of the neurotic hypochondriacs? Or the paranoid new parents obsessing over each cough and sniffle of their new baby - both of whom might have > 10 health monitoring applications?

This hilites a key problem with native applications - their lifecycle (discover, install, login, use, manage, remove) doesn't scale particularly well for the user. App stores make the first two trivially easy (arguably too easy), but dont help much with the steps that follow.

The problem will only get worse when it's not only personal health monitoring devices that we will want to be able to interact with, but everything. When my fridge, washing machine, dishwasher, printer, garage door opener, mailbox, and TV remote are all collecting data and clamoring for my attention to view, analyze, and act on that data - do I want a separate native application for each of them? No I do not.

If only there were an alternative to the native application model - one where application functionality can be downloaded in real-time, rather than a priori installed.....

Which begs the question ....

2013-04-30T12:44:00.002-04:00

In YAPAUOFA (Yet Another Post About Using OAuth For Authentication) I argue (following the lead of John and Vittorio) that the issue with trying to use OAuth OOB for authentication is that a Client can use a token it obtains 'fairly' in order to impersonate the corresponding user at some other Client.

Necessarily then, a Client has gone 'bad'.

Why then is this not an issue for the use case that OAuth was designed for, ie delegated authorization of API access? Could not such a Client also go 'bad' and do similarly malicious things?

In the delegated access use case for OAuth, all that an access tokens 'means' is that it allows a Client to access the corresponding User's protected resources. Clearly a Client can go bad and share this access token and (in a bearer token model) anybody else who obtains that token will also be able to access those same resources. Critically, all these additional Clients will only enjoy the permissions allowed by the scope attached to the original token.

As John points out

In the authorization case the client can be trusted with the access token because it has no real motivation to share it. They could give it to a third party and also grant them access to the information(protected resource), but they can just share the information anyway if they are bad

Yes the Client can go bad and share the access token. But it already has access to the protected resources and can already do all the evil operations it desires against those resources. The fact that a shared token will allow multiple bad Clients to perform evil operations instead of only the original bad Client probably wont matter much to the user.

So in the authorization case, if a Client goes bad - it doesn't really matter whether that evil manifests as that Client doing malicious things with the token, or rather sharing that token and allowing other bad Clients to do the malicious things. Put another way, sharing the token doesn't change the 'scope' of the possible damage.

But this isn't the case when basic OAuth is used for authentication. If a malicious Client can use its own token to impersonate a User at some other (non-evil) Client, then the scope of the attack expands greatly - to include all the damage that malicious Client can do at the other Client.

YAPAUOFA (Yet Another Post About Using OAuth For Authentication)

2013-04-30T10:02:00.002-04:00

As both John and Vittorio have written (extensively) on the matter, I will be brief.

The fundamental problem with using OAuth (with no additional constraints) for authentication is that it relies on the following premise

‘If I can enable the delivery of a valid access token to a Client, then I can lay claim to the identity represented by that access token at the corresponding AS.’

So, if an attacker (acting as a normal OAuth Client, albeit one with evil in its heart) can obtain a valid access token for a User Bob from a valid AS, it can present it to a different valid Client and have the following conversation

Attacker->Client: Here is a token

Client->AS: tell me about the User associated with this token

AS->Client: that token is good and refers to Bob

Client to itself: Hmm, well it meets the criteria ……

Client->Attacker: Welcome Bob

Attacker->Client: Err, hi, yes well of course I'm Bob. Let's start moving $$

The core problem is that the valid Client is unable to distinguish between a token previously handed to the Attacker, and a valid token being delivered via the real Bob.

So why not add something to the token to make that distinction easy for the valid Client, so the conversation now becomes

Attacker->Client: Here is a token

Client to itself: Whoaaa, this token is not for me!!!

Client->Attacker: Nice try bud

That is what OpenID Connect does, the OIDC id_token carries the audience (in the aud param) to which the token was issued, preventing it from being presented elsewhere. If an OIDC Client is presented with an id_token with an audience not itself, it will stop the login process.

Facebook Connect similarly restricts the audience, but does so implicitly by requiring that the Client validate a signature calculated over the signed_request. If a Client can't validate the signature, it will know that something is up and abort.

Persona UX

2013-04-30T07:33:00.000-04:00

You start off at the SP

The SP sends you to the IdP (of which there is 1? there was no discovery step)

I am going to log in to Persona.

How long?

I'm in

New line of greeting cards

2013-04-30T07:32:00.000-04:00

The hip bone is connected to the thigh bone ....

2013-04-15T08:39:00.002-04:00

The graphic below represents the 'chain of secrets' for OAuth - showing how it is the logical combination of a client & a user (as represented by their secrets) that are combined into OAuth tokens for use on API calls.

After authenticating to an OAuth Authorization Server with it's password (green 'Pwd'), a User grants to a given Client an authorization grant, as manifested in an authorization code (green 'Code').

An OAuth Client exchanges that code for a Refresh Token (Green 'Rt'), using its client secret (red 'Cs') on the request.

The OAuth Client can exchange the refresh token for Access Token (green 'At'), also using its client secret on the request.

The Access Token is then presented by the Client to the REST endpoint (yellow 'API') , as proof that the User has previously made the grant (ie gave their consent).

For native clients, it's unrealistic to expect that the app could be distributed (through an app store) with a secret (such as 'Cs') so instead the app can be distributed with a global Application Secret (red 'As'), this subsequently exchanged for a unique Cs (as in the dynamic registration spec).