Tag Archives: IIW

New: Musings on SCIM after IIW

Over on the Forrester blogs, I talk about the latest progress on Simple Cloud Identity Management (SCIM), as seen and discussed at IIW.

(I’ll be at Forrester Security Forum November 9-10, in lovely Miami — you going?)

New: “Protecting Internal APIs – Is OAuth Ready For Its Closeup?”

Check out my new post on the Forrester blog, looking to hear about your experience and opinions on the use of OAuth to secure your internal app landscape. You know you have stories. I know you have stories. So why not share them??

I hosted a session at IIW last week to start collecting data around this topic, impishly/illicitly called Two Legs Good? (since the OAuth community keeps trying to quit the “legs” habit but can’t seem to manage it). Session notes are at the link. IIW totally rocked this time; thanks to the organizers and all who contributed to making it great!

In order to encourage you to comment over on the other site, I’ve turned off comments here (boy, does that feel weird…). If you prefer to weigh in with 140 characters’ worth of wisdom, just be sure to use the hashtag #Forr2Legs so I’ll see it.

How UMA deals with scopes and authorization

The UMA group has been quite busy of late. Like several other efforts (don’t miss John Bradley’s OpenID ABC post or anything Mike Jones has been blogging in the last few months), we’ve been gearing up for IIW 12 as a great place to try out our newest work, figure out the combinatorial possibilities with all the other new stuff going on, and get feedback.

Newcastle University’s SMART project team will be in Mountain View again, discussing their UMA implementation and UX work. And vice-chair Maciej Machulak and I plan to convene a session to share our draft solution for loosely coupling an OAuth authorization server and resource server to solve for externalized authorization and interoperable scoped access in the UMA context.

Back in February, a bunch of us tried discussing this very subject in Twitter and got pretty far, but it took Paul Madsen to put the whole story together in his blog post Way more than 140. And loving it. Check it out.

Essentially, UMA is choosing to give the host (resource server) more autonomy than it would typically have in a tightly coupled environment, so that it’s not entirely accurate to say it’s a mere policy enforcement point (PEP) and the authorization manager (authz server) is a full policy decision point (PDP). This seems to make good sense in a totally open-Web environment. However, “the full PDP” is an optional feature we could probably add if there’s interest.

The really interesting thing is that, to make externalized authorization work, we’ve had to go “radically claims-based”. The model seems very powerful and generative — it gives the power to upgrade and downgrade granted scopes at will! But it does take a step or two back from pure OAuth 2.0 as a result. This is something I’m keen to discuss with folks in and around IIW; we’ll be presenting these slides to that end.

UMA meeting co-located with IIW and other news

Thanks to Phil and Kaliya and the gang, I’m happy to say we’re holding an UMA face-to-face meeting at the Computer History Museum on the Monday just prior to IIW XI (pronounced “yewksie”?).

This follows close on the heels of a face-to-face in Paris at the Kantara conference, so I hope we’ll be able to crank through a lot of work in the next few weeks. What work, you ask? We’re shooting for draft completion of some key items in the upper box shown here (click to get to a full-size site-mapped version on our Working Drafts page):

I’ve already gotten several requests for more info about the IIW meeting. These will be working meetings, not public transfer-of-information workshops, and we always welcome new participation. You can become a participant (voting/frequently attending or non-voting/attend at will, totally up to you) by filling out this form. I’ve put up some very preliminary agendas (Paris, Mtn View); they tend to be responsive to work done in weeks prior, so check back.

(UPDATE: There’s no formal registration process for the IIW meeting as long as you’re already signed up as an UMA participant; just send me an RSVP. Contact info is under my Welcome section in the right sidebar.)


Did you know our Newcastle University UMAnitarians have begun open-sourcing their Java implementation? The first big piece from the SMART Project covers UMA-friendly OAuth 2.0 and has the lovely name leeloo. They promise more to come soon, and I bet we’ll see some swank demos at IIW. Check it out!

OpenID and OAuth: As the URL Turns

In Phil Windley’s initial IIW wrap-up, he alluded to the soap-opera nature of the OpenID wrangling that went on last week. It’s an apt description.

soap

In the spirit of real ones:

Margo wanted Parker to get an attorney before making a confession but he insisted on telling the truth anyway. Margo quickly called Jack with the latest development so he and Carly rushed to the station. Jack ordered his son to keep quiet but Parker said he was going through with his confession. Carly was brokenhearted that Parker couldn’t be silenced and Margo took Jack off the case. [ATWT]

…I present the soap-opera synopsis of the goings-on:

David showed up at the Mountain View party with OpenID Connect, which had been hanging around with OAuth in a way that seemed promiscuous. Having insisted last year that it was ready to change, OpenID quickly got busy. OpenID Artifact Binding was brokenhearted that its quiet yet effective nature wasn’t enough to get it noticed. UMA and CX couldn’t help putting in their two cents when they heard what the problem was.

The OpenID specs list discussion is now hopping, and so far it’s been relatively free of pique and getting more productive as people understand each other’s use cases and requirements better. Now we just need to come up with a list of in-scope ones…and realize that the best ideas for solving each one could come from anywhere.

So: Can we try and combine the grand vision and breadth of community of the OpenID.next process, the rigor and security of OpenID AB, and the speed and marketing savvy of OpenID Connect — rather than (ahem) the speed and rigor of the OpenID.next process, the grand vision and marketing savvy of OpenID AB, and the security and breadth of community of OpenID Connect?

UPDATE on 10 July 2010: This post has been translated into Belorussian by PC.

Comparing OAuth and UMA

UMA logo

The last few weeks have been fertile for the Kantara User-Managed Access work. First we ran a half-day UMA workshop (slides, liveblog) at EIC that included a presentation by Maciej Machulak of Newcastle University on his SMART project implementation; the workshop inspired Christian Scholz to develop a whole new UMA prototype the very same day. (And they have been busy bees since; you can find more info here.)

Then, this past week at IIW X, various UMAnitarians convened a series of well-attended sessions touching on the core protocol, legal implications of forging authorization agreements, our “Claims 2.0″ work, and how UMA is being tried out in a higher-ed setting — and Maciej and his colleague Łukasz Moreń demoed their SMART implementation more than a dozen times during the speed demo hour.

In the middle of all this, Maciej dashed off to Oakland, where the IEEE Symposium on Security and Privacy was being held, to present a poster on User-Managed Access to Web Resources (something of a companion to this technical report, all with graphic design by Domenico Catalano).

Through it all, we learned a ton; thanks to everyone who shared questions and feedback.

Because UMA layers on OAuth 2.0 and the latter is still under development, IIW and the follow-on OAuth interim F2F presented opportunities for taking stock of and contributing to the OAuth work as well.

Since lots of people are now becoming familiar with the new OAuth paradigm, I thought it might be useful to share a summary of how UMA builds on and differs from OAuth. (Phil Windley has a thoughtful high-level take here.) You can also find this comparison material in the slides I presented on IIW X day 1.

Terms

UMA settled on its terms before WRAP was made public; any overlap in terms was accidental. As we have done the work to model UMA on OAuth 2.0, it has become natural to state the equivalences below more boldly and clearly, while retaining our unique terms to distinguish the UMA-enhanced versions. If any UMA technology ends up “sedimenting” lower in the stack, it may make sense to adopt OAuth terms directly.

  • OAuth: resource owner; UMA: authorizing user
  • OAuth: authorization server; UMA: authorization manager
  • OAuth: resource server; UMA: host
  • OAuth: client; UMA: requester

Concepts

I described UMA as sort of unhooking OAuth’s authorization server concept from its resource-server moorings and making it user-centric.

  • OAuth: There is one resource owner in the picture, on “both sides”. UMA: The authorizing user may be granting access to a truly autonomous party (which is why we need to think harder about authorization agreements).
  • OAuth: The resource server respects access tokens from “its” authorization server. UMA: The host outsources authorization jobs to an authorization manager chosen by the user.
  • OAuth: The authorization server issues tokens based on the client’s ability to authenticate. UMA: The authorization manager issues tokens based on user policy and “claims” conveyed by the requester.

Dynamic trust

UMA has a need to support lots of dynamic matchups between entities.

  • OAuth: The client and server sides must meet outside the resource-owner context ahead of time (not mandated, just not dealt with in the spec). UMA: A requester can walk up to a protected resource and attempt to get access without having registered first.
  • OAuth: The resource server meets its authorization server ahead of time and is tightly coupled with it (not mandated, just not dealt with in the spec). UMA: The authorizing user can mediate the introduction of each of his hosts to the authorization manager he wants it to use.
  • OAuth: The resource server validates tokens in an unspecified manner, assumed locally. UMA: The host has the option of asking the authorization manager to validate tokens in real time.

Protocol

UMA started out life as a fairly large “application” of OAuth 1.0. Over time, it has become a cleaner and smaller set of profiles, extensions, and enhanced flows for OAuth 2.0. If any find wider interest, we could break them out into separate specs.

  • OAuth: Two major steps: get a token (with multiple flow options), use a token. UMA: Three major steps: trust a token (host/authorization manager introduction), get a token, use a token.
  • OAuth: User delegation flows and autonomous client flows. UMA: Profiles (TBD) of OAuth flows that add the ability to request claims to satisfy user policy.
  • OAuth: Resource and authorization servers are generally not expected to communicate directly, vs. through the access token that is passed through the client. UMA: Authorization manager gives host its own access token; host uses it to supply resource details and request token validation.

Much work remains to be done; please consider joining us (it’s free!) if you’d like to help us make user-managed access a reality.