Phil Hunt shared some musings on OAuth and UMA recently. His perspective is valuable, as always. He even coined a neat phrase to capture a key value of UMA’s authorization manager (AM) role: it’s a user-centric consent server. Here are a couple of thoughts back.
In the enterprise, an externalized policy decision point represents classic access management architecture, but in today’s Web it’s foreign. UMA combines both worlds with the trick of letting Alice craft her own access authorization policies, at an AM she chooses. She’s the one likeliest to know which resources of hers are sensitive, which people and services she’d like to share access with, and what’s acceptable to do with that access. With a single hub for setting all this up, she can reuse policies across resource servers and get a global view of her entire access landscape. And with an always-on service executing her wishes, in many cases she can even be offline when an access requester comes knocking. In the process, as Phil observes, UMA “supports a federated (multi-domain) model for user authorization not possible with current enterprise policy systems.”
Phil wonders about privacy impacts of the AM role given its centrality. In earlier federated identity protocol work, such as Liberty’s Identity Web Services Framework, it was assumed that enterprise and consumer IdPs could never be the authoritative source of all interesting information about a user, and that we’d each have a variety of attribute authorities. This is the reality of today’s web, expanding “attribute” to include “content” like photos, calendars, and documents. So rather than having an über-IdP attempt to aggregate all Alice’s stuff into a single personal datastore — presenting a pretty bad panoptical identity problem in addition to other challenges — an AM can manage access relationships to all that stuff sight unseen. Add the fact that UMA lets Alice set conditions for access rather than just passively agree to others’ terms, and I believe an AM can materially enhance her privacy by giving her meaningful control.
Phil predicts that OAuth and UMA will be useful to the enterprise community, and I absolutely agree. Though the UMA group has taken on an explicitly non-enterprise scope for its initial work, large-enterprise and small-business use cases keep coming up, and cloud computing models keep, uh, fogging up all these distinctions. (Imagine Alice as a software developer who needs to hook up the OAuth-protected APIs of seven or eight SaaS offerings in a complex pattern…) Next week at the Cloud Identity Summit I’m looking forward to further exploring the consumer-enterprise nexus of federated access authorization.
Sort of off-topic comment. May be more related to your tweet, “I want to allow most #OAuth connections as read-only; too many want read/write for no good reason. Services, please make this an option!”
Recently I have been looking at how Google Apps Marketplace apps utilize OAuth to access user’s Google Apps data. It is all or nothing access. Once Google Apps domain administrator adds a Marketplace Apps to the domain, the app gets full access all the data in the entire domain. This kinda worries the Data Custodians, and rightfully so.
Here are somethings, if implemented, may calm the fears of the data custodians:
1) Controls to prevent mis-use of this over-reaching authorizations;
2) Granular policy controls, i.e. ability to give read-only access to pre-defined data for users who will be using the apps;
3) A view into detailed logs of access and audit logs;
4) Anomaly detection system.
I am not sure how UMA can help in this area, but would like to hear your thoughts.
Saqib
Hi Saqib– Thanks for your thoughtful comment.
There is a business-level problem here (relying parties would prefer getting as much access as possible), and also a technical problem (defining “scope” of access in an interoperable way is hard, as evidenced by the OAuth group’s decision to punt on semantics for this field).
I think UMA should ideally be able to pick up whatever technical solution wins the day, but we did propose a solution to the wider community that relies on “extreme RESTfulness” of the API being accessed to achieve interop. If an API can be described meaningfully as a set of triples of resource URL/HTTP method/semantic, then the first two parts could be encoded (we proposed a JSON format) as a way to ask for and grant that kind of access in an OAuth or UMA ecosystem. It’s more wordy than 100% of the OAuth deployments on the planet, but it can at least be consistently applied.
So that’s the technical problem. My hope is that the business-level problem can be tackled piecemeal at the UMA level by giving users better tools to offer valuable data on their own terms. Changing them from passive to active participants (through the assistance of an AM) should change the incentives a bit.
Further thoughts welcome…
Eve,
I like how you make the distinction between business-level problem vs. technical problem. Like you said, relying parties (3rd party app vendors) would like as much access as possible. But I also think that the technological solutions (for e.g. OAuth) should default to user’s predefined settings regardless of how the service provider sets up the Authorization. Unless I am missing something, I am not seeing this being addressed anywhere.
Saqib
At the UMA table we’re trying to address at least some of this, e.g., with the notion of a “resource registration API” and with user-dictated policy that in many cases can be enforced without the user being around, but indeed it’s tricky…