Ultimately, I think User's need to be able to define authorization rules for their identity attributes in terms of both
1) the requesting actor (Consumer in OAuth/ProtectServe, WSC in ID-WSF)
2) an individual with some defined social relationship to themselves
ProtectServe's AM is designed to simplify for User's the definition and management of the first type of authz rules, Liberty's People Service the second.
Of course the mention of ProtectServe is referencing the recent work of Eve Maler and team regarding a proposal to help simplify authorization management for users in the "distributed web".
I believe that it should be possible to extend the Authorization Manager (AM) to leverage social relationships as a mechanism for the user to control access to protected resources. One of the use cases Eve mentions in this post is ...
Making an album’s worth of photos from the latest vacation available to some group of friends and family, but reserving a few in the same album for a more select group
Paul correctly points out that the Liberty Alliance People Service is built for just such a task. As it turns out Portable Contacts provides very similar functionality and is based on OAuth (the same base as ProtectServe). The Portable Contacts (PoCo) specification allows for grouping of contacts in an arbitrary manner using tags so the examples Paul gives are easily mapped. One missing feature of the current PoCo spec is that it doesn't support "membership queries" which means that more information is leaked to the Service Provider than necessary.
Let's look at this use case in more detail. Assuming that Alice has created a resource at her photo service for the vacation photos, and also assuming that Alice has identified the desired set of individuals in her PoCo service with a tag of 'VacationPhotos', all Alice needs to do is associate this tag with the desired resource. So let's assume this is possible within the AM. Finally, let's assume that Bob is one of the individuals with a 'VacationPhotos' tag in Alice's PoCo service.
The basic flow is that Alice sends Bob the link for the protected vacation photos. Bob clicks on the link and is taken to the photo service via his browser. The photo service check with the AM to determine whether the resource is protected or not. Since the resource is protected, the photo service asks Bob to authenticate. Based on Bob's authentication, and his membership in Alice's 'VacationPhotos' group, Bob is given access to the photos.
The interesting twist with this particular use case is that the "Consumer" is really a user (i.e. Bob) who wants to view Alice's vacation photos. So when Bob tries to access the vacation photos resource that Alice shared with him, he accesses the service provider directly. At this point the SP checks with the AM regarding the authorization rules for the resource. However, Bob doesn't have a Consumer "token and secret" with which to sign his request to the SP. Instead he is accessing the SP directly via his user-agent. What Bob can do is authenticate himself to the SP using some authentication means. This is necessary as an identifier is required to determine membership in Alice's 'VacationPhotos' group.
This leads to the question of who should manage the relationship with Alice's PoCo service to do the "membership" check? I can see two options...
The AM maintains the authorization requirement (e.g. consumer must be member of Alice's VacationPhotos group) but the SP does the actual membership check. In this model the SP needs to set up a ProtectServe based relationship with Alice's PoCo service. Then when the SP authenticates Bob and has an identifier for him, it can check directly with the PoCo service determining membership based on the "contract" received from AM. This means that the SP must be able to interpret and process the "contract" on behalf of AM.
The AM maintains the authorization requirement and also does the membership check with the PoCo service. In this model, the SP will need to forward Bob's identifier to the AM in order for the AM to perform the "membership" check and determine the state of the authorization. Or the SP could redirect Bob to the AM but I would that such a UX would most likely confuse the user. I do think there is a interesting privacy question on whether the SP should be allowed to forward Bob's identifier to the AM without Bob's consent.
I'm not sure which method I like better. Maybe others have better solutions. Thoughts?
Update: Corrected my ProtectServe typos:)
3 comments:
True, my 'division of roles' didnt account for the Consumer and InvokingIdentity being collapsed together as in your use case
With respect to your 2 options, there will be cases where the SP will wish to interact with the PoCo for reasons unrelated to authz - perhaps arguing for Option 1.
You mention 2 options for "...the question of who should manage the relationship with Alice's PoCo service to do the 'membership' check..." but there is a third way.
The Authorization Mgr can use an authentication service provider (IDP) (federated/carspace-based/OpenID-based) to authenticate Bob then present the SP with an authorization token on Bob's behalf. The AM must have a pre-existing way of knowing Bob (since Alice has put him into a bgroup) so there's no privacy issue in the exchange between the AM and the IDP and since no PII is exchanged with the SP, there's no privacy issue there either.
-dave
Dave, good point. The AM can authenticate Bob and hence manage the "membership check" without any exposure of PII. The only potential concern I have here is a UX one.
For Bob to get access to Alice's photos, he follows the link to the SP. At this point the SP will have to redirect Bob to the AM for Bob to authenticate and the AM perform the "membership check". Then the AM will need to redirect Bob back to the SP with a "yes/no" authorization statement.
As a user, I'd prefer to avoid the redirect if possible.
Post a Comment