Wednesday, April 06, 2011

A token argument for lazy deprovisioning

When an employee can only access cloud applications through SSO from their enterprise deprovisioning employees as they 'leave to purse other career opportunities' is easy - the enterprise simply turns off the ability to SSO (by turning off the ability to authenticate to the enterprise). For accessing cloud applications through the browser - the enterprise acts as a gatekeeper for its employees to the Cloud - and so becomes an effective shut-off valve when needed.

As the enterprise can be confident that the Recently Boxed Up Employee (RBUE) no longer has access to cloud applications - it may choose to be somewhat relaxed about cleaning up any remnants of those ex-employees at the various SaaS providers. The motivation is more about data hygiene and less about security - and so there need not be the same urgency to the clean up.

This laissez faire attitude changes if the RBUE had also been able to access the cloud applications through a native application on their phone (or yes, tablet, these days you have to mention tablets). Unlike for Web SSO, the authentication model for such native installed mobile applications does not typically (caveat,caveat, caveat) involve the enterprise at run-time. Instead, the application is issued (for the relevant employee) relatively long-lived tokens at registration time, and it is by presenting these tokens to the Cloud APIs fronting the data that the application authenticates (for the relevant employee).

While the enterprise was (likely/hopefully) involved (if not directly) in the original process of issuing the tokens to the native applications - it is not typically (caveat,caveat, caveat) involved in the subsequent run-time issuance or verification of those tokens when presented by the native applications (e.g. the Cloud provider wouldn't typically call-out to the enterprise asking

Have you fired this guy yet? FYI, he spends most of his time on Chatter talking about baseball

As it's not involved in the day-to-day issuance and/or verification of the tokens that the native application uses to authenticate to the Cloud - the enterprise can't play the passive shut-off role possible for Web SSO - it can't stop RBUE access to the Cloud by simply stopping issuing tokens for that RBUE.

Instead, the enterprise needs to get up off its corporate butt and actively deprovision the RBUE (the same operation required as when, before Cloud SSO was possible, each employee had particular accounts and passwords at SaaS providers).

No longer can the enterprise spend its time watching Oprah - secure in the belief that turning off SSO effectively terminates Cloud access for the RBUE. The enterprise needs to actively (and promptly) reach out to each and every relevant Cloud provider and send the 'Delete user' message (specifics varying according to the proprietary user management API each Cloud API offers up).

Sorry Oprah.

This argument presumes that the tokens are issued to the native application by the Cloud provider, and not the enterprise. This seems to be today's reality. In this model, the tokens aren't federated - the Cloud issues tokens that it will subsequently verify. JWT will likely enable a different model, where an enterprise can issue a token to the native application, and a Cloud API can verify it. In such a model, the enterprise regains the right to be lazy about 'deprovisioning'.

No comments: