User managed access

While attending the 10th Internet Identity Workshop last week, I came across an interesting initiative that I had absolutely no idea about. I am glad that I attended. It is called User Managed Access (UMA). It is about letting a user choose the access control policies for resources offering his/her personal data (personal information, address book, bookmarks, blog posts, comments, etc.). It is explained much better in UMA Explained.

"... a web user (authorizing user) can authorize a web app (requester) to gain one-time or ongoing access to a resource containing his home address stored at a "personal data store" service (host), by telling the host to act on access decisions made by his authorization decision-making service (authorization manager)."

If you are familiar with enterprise access control, the following might help.

"In enterprise settings, application access management often involves letting back-office applications serve only as policy enforcement points (PEPs), depending entirely on access decisions coming from a central policy decision point (PDP) to govern the access they give to requesters. This separation eases auditing and allows policy administration to scale in several dimensions. UMA makes use of this separation, letting the authorizing user serve as a policy administrator crafting authorization strategies on his or her own behalf."

The UMA work group has protocol spec, scenarios and reference implementation.

I plan to follow this work. Having just checked in the default set of permissions for resources for CollectionSpace, I wonder how and when a Host (such as CollectionSpace) would make permissions for a user's data available to an Authorization Manager (AM). UMA envisions that the AM could be a third party web-based service, but would that be practical from a performance perspective?

 

Authorization service RESTful interface

Yesterday, I checked in the last piece of functionality to complete the first pass at the RESTful interface of the authorization service in CollectionSpace. There is a short description of these APIs on the wiki. Yes, I am aware of the confusion behind the term authorization. I have described the terms used on the wiki.

1. Role
2. Permission
3. Role - Permission relationship (available from Permission service, /permissions/{id}/permroles)
4. Account - Role relationship (available from Account service, /accounts/{i}/accountroles)

Indeed, there is a separate web service for account management with its own RESTful interface. The CollectionSpace security runtime exposes APIs to enforce access control from the CollectionSpace services runtime and SPIs to plug in various providers. I will be using Spring Security ACLs as the underlying service provider.

More on the enforcement of the permissions in future entries. I will also write more about my experiences and approaches I took in implementing relationships between RESTful resources, e.g. relationship between Role and Permission.