Wednesday, August 24, 2011
Thursday, August 11, 2011
Wednesday, August 10, 2011
Friday, July 15, 2011
Thursday, July 14, 2011
Friday, June 24, 2011
Tuesday, June 07, 2011
Friday, June 03, 2011
Friday, May 20, 2011
Sunday, May 15, 2011
Wednesday, May 04, 2011
Tuesday, May 03, 2011
Friday, April 29, 2011
Scoping scope
ReadWriteWeb describes Twitter's new consent UI by which an application asks of a user access to their Twitter account.
Aside: RWW describes this page as the 'OAuth screen', makes just as much sense to call it the 'HTTP screen'. OAuth is the plumbing for this screen, not the (visible) shower curtain.
RWW points out that the list of allowed actions isn't quite as complete as indicated. Notably omitted from the list is 'Read that DM where you made fun of your boss's new haircut'.
The UI might make a user believe that this list of permissions is unique to Favstar.FM. But that's not the case - these are generic permissions, afforded to all (registered) applications. The only differentiation in permissions that Twitter supports is between 'read' & 'read and write', this selected by the application developer at registration time
Twitter's model ignores a key advantage of the OAuth model (one not supported by the password anti-pattern), namely allowing a user to give differentiated permissions to different applications.
Separately:
Aside: RWW describes this page as the 'OAuth screen', makes just as much sense to call it the 'HTTP screen'. OAuth is the plumbing for this screen, not the (visible) shower curtain.
RWW points out that the list of allowed actions isn't quite as complete as indicated. Notably omitted from the list is 'Read that DM where you made fun of your boss's new haircut'.
The UI might make a user believe that this list of permissions is unique to Favstar.FM. But that's not the case - these are generic permissions, afforded to all (registered) applications. The only differentiation in permissions that Twitter supports is between 'read' & 'read and write', this selected by the application developer at registration time
Twitter's model ignores a key advantage of the OAuth model (one not supported by the password anti-pattern), namely allowing a user to give differentiated permissions to different applications.
Separately:
- Red & green text? Really?
- Does the stuttering repetition of 'Favstar.FM' imply a glitch in the code? or an overzealous registration page?
- The list of things the app will not be able to perform seems incomplete. I suggest the following additions at minimum
Saturday, April 16, 2011
Not on the first date
My Ping colleague Travis blogged yesterday on a POC he put together with Axiomatics David Brossard.
Travis used some security terms I was unfamiliar with (e.g. 'fika', 'bullar'?) but I believe the jist of the POC is that:
a) a user can be introduced to a bank (or equivalent) through some existing social identity(e.g. facebook, Twitter, etc) they have
b) they can enjoy a richer experience because of the information made available to the bank (e.g. services customized to their location, etc) from the social provide
c) if they actually want to become a customer of the bank, the normal (and far more rigorous) procedure of proofing, registration, and issuance kicks in - the same process as would happen if the user hadnt first been introduced by the social provider
I think of the value of the introduction step as smoothing out the 'hassle as function of relationship maturity' curve.
The current default is that there are two possible states for a given user's relationship with a provider (bank or otherwise) - a) member of the unwashed horde or b) customer.
The transition from a) to b) can be onerous - and critically, the hassle may not be commensurate with the user's own assessment of where they are in the relationship with the provider. The situation is shown in the graphic below
The user may have been thinking they just wanted to 'hold hands' but the provider is all hot & heavy and saying 'lets do this, lets do this' etc etc
The model the POC enables is shown in the diagram below. The introduction of the user to the bank, while not enabling the same richness of experience and service as a full account (with associated hassle) still provides something richer than the unwashed status. Importantly, its likely a degree of hassle more inline with the user's own feeling for the relationship with the bank. There is a middle ground - a 'lets cuddle' stage if you will (or won't - that's your decision, no pressure from me)
If the relationship matures further, and the creation of a 'real' account is deemed necessary - the user will hopefully be convinced of the value of taking on the hassle - having already established some confidence in the provider.
Lets keep the pressure to be 'socially promiscuous' off the Web, and in high school where it belongs.
Travis used some security terms I was unfamiliar with (e.g. 'fika', 'bullar'?) but I believe the jist of the POC is that:
a) a user can be introduced to a bank (or equivalent) through some existing social identity(e.g. facebook, Twitter, etc) they have
b) they can enjoy a richer experience because of the information made available to the bank (e.g. services customized to their location, etc) from the social provide
c) if they actually want to become a customer of the bank, the normal (and far more rigorous) procedure of proofing, registration, and issuance kicks in - the same process as would happen if the user hadnt first been introduced by the social provider
I think of the value of the introduction step as smoothing out the 'hassle as function of relationship maturity' curve.
The current default is that there are two possible states for a given user's relationship with a provider (bank or otherwise) - a) member of the unwashed horde or b) customer.
The transition from a) to b) can be onerous - and critically, the hassle may not be commensurate with the user's own assessment of where they are in the relationship with the provider. The situation is shown in the graphic below
The model the POC enables is shown in the diagram below. The introduction of the user to the bank, while not enabling the same richness of experience and service as a full account (with associated hassle) still provides something richer than the unwashed status. Importantly, its likely a degree of hassle more inline with the user's own feeling for the relationship with the bank. There is a middle ground - a 'lets cuddle' stage if you will (or won't - that's your decision, no pressure from me)
Lets keep the pressure to be 'socially promiscuous' off the Web, and in high school where it belongs.
Friday, April 15, 2011
Thursday, April 14, 2011
Thursday, April 07, 2011
More token taxonomizing
Generally, APIs fall into one of two categories – either SOAP-based or REST-based. SOAP defines an XML messaging envelope for carrying payload and associated metadata. SOAP messages are typically delivered over HTTP as POSTs – the semantics of the message carried in the SOAP Body within the HTTP body. Advocates of REST argue that HTTP itself offers all the desired semantics through its built-in support for GET, PUT, POST, DEL etc. There is much emotion on both sides. Regardless, both SOAP and REST APIs rely on tokens to carry security information.
API Clients typically interact with some sort of 'token service' to get a token, and then include that token on their calls to the API - the token layers on the security information the API needs to make an authorization decision. For the SOAP world, WS-Trust defines the protocol between the Client and the token service by which the Client gets the necessary toklens. In the REST world, OAuth does the equivalent.
Tokens can be distinguished along a number of (somewhat) orthogonal axes:
API Clients typically interact with some sort of 'token service' to get a token, and then include that token on their calls to the API - the token layers on the security information the API needs to make an authorization decision. For the SOAP world, WS-Trust defines the protocol between the Client and the token service by which the Client gets the necessary toklens. In the REST world, OAuth does the equivalent.
Tokens can be distinguished along a number of (somewhat) orthogonal axes:
- artifact or assertion - does the token have internal structure with heterogeneous elements within? Or is an opaque blob like a random text string that have no inherent meaning or semantics, but acts only as a reference or pointer into some store – the referenced object likely having the semantics. The artifact model has advantages when the delivery channel is constrained in security or size-limits
- Security model - what is required of the Client for presenting a token to some API? Is mere possession of the token sufficient (the bearer model), or is the Client required to demonstrate knowledge of some secret associated with the token (the POP or proof-of-possession model)?
- Implicit or explicit security. Does the token carry within itself its own inherent security protections, ie is there a space to carry a signature for the token, thereby allowing a recipient to determine the issuer of the token? Alternatively, does the token itself rely on external security protection, e.g. provided by the transport channel over which it is sent
- Standardized or proprietary – is the structure (if present) of the token defined by some group – or is it proprietary to a single issuer (or recipient). The criteria as to what constitutes ‘some group’ varies. If the same entity both issues and verifiers the tokens - there is less motivation for a standard (assuming they are opaque to the client)
- Duration - are they long-lived or short-lived? Generally, bearer tokens are given short lifetimes to balance the risk of their theft.
Wednesday, April 06, 2011
From Properties to Capabilities
Hal Lockhart has an interesting post on different authorization models, distinguished by the nature of the claims/attributes made within some token/assertion. Hal argues that there is a spectrum between 'properties' (where the attributescontain information about who/what the Subject is) and 'capabilities' (where the attributes contain information about what the Subject is allowed to do).
Coincidentally, I was working at my 'drawings' this morning - sketching out something similar for OAuth.
The diagram below shows three different models for the interaction between OAuth Client, Authorization Server, and Resource Server.
In the top model, the Client requests of the OAuth AS a token, but does not specify any particular RS target. Consequently, the AS can issue a token with claims that contain only generic attributes of the Client/Subject. This is Hal's properties model. The AS authenticates, the RS authorizes.
In the bottom model, the Client includes in its request to the AS the scope of what actions it desires to perform at the RS. The token that the AS subsequently issues reflects a positive authorization decision and not some generic attribute of the Client. This is Hal's capabilities model. The AS makes an authorization decision and tells the RS about it. Makes for simple RSs.
Reflecting the delegated authorization use case that originally motivated OAuth - it is the capabilities model that gets the most attention. The assumption is that the OAuth access token issued to the Client reflects a set of capabilities assigned to it by the Resource Owner. But there are lots of applications of OAuth where the access token wont reflect capabilities but simply Client properties.
Note: The middle model has the respponsibility for the complete authorization decision shared amongst the AS & RS. It is there because any good taxonomy has at least 3 permutations - I have nothing more to say about it.
Coincidentally, I was working at my 'drawings' this morning - sketching out something similar for OAuth.
The diagram below shows three different models for the interaction between OAuth Client, Authorization Server, and Resource Server.
In the top model, the Client requests of the OAuth AS a token, but does not specify any particular RS target. Consequently, the AS can issue a token with claims that contain only generic attributes of the Client/Subject. This is Hal's properties model. The AS authenticates, the RS authorizes.
In the bottom model, the Client includes in its request to the AS the scope of what actions it desires to perform at the RS. The token that the AS subsequently issues reflects a positive authorization decision and not some generic attribute of the Client. This is Hal's capabilities model. The AS makes an authorization decision and tells the RS about it. Makes for simple RSs.
Reflecting the delegated authorization use case that originally motivated OAuth - it is the capabilities model that gets the most attention. The assumption is that the OAuth access token issued to the Client reflects a set of capabilities assigned to it by the Resource Owner. But there are lots of applications of OAuth where the access token wont reflect capabilities but simply Client properties.
Note: The middle model has the respponsibility for the complete authorization decision shared amongst the AS & RS. It is there because any good taxonomy has at least 3 permutations - I have nothing more to say about it.
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'.
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'.
Subscribe to:
Posts (Atom)