There are a bunch of issues open on the UMA spec that are currently
awaiting assignment to some future revision of the specification as
they’d break backwards compatibility in a not-fun fashion. Instead of
simply letting these languish here awaiting their time in the
spotlight, we decided to go ahead and implement them all together
using MITREid Connect (an UMA 1.0.1 implementation) as a base.
Changes include:
Removal of the RPT endpoint, in favor of using the token endpoint
and a new grant type (#153)
Removal of the AAT (#154)
Removal of extraneous bits of the resource set registration URL
pattern (#155)
Alignment of the discovery document with OIDC discovery (#157)
Removal of “version” field in discovery document, instead document
is published under new .well-known URL pattern (#159)
Change use of “scopes” name in responses to something more explicit (#158)
Ability of client to specify scopes in token request (#165)
Addition of the claims-gathering URL to the need_info response,
removal of “redirect_user” as redundant in this case (#167)
Simplification of the “need_info” response structure, removal of
extraneous object layers (#237)
Rotation of ticket values on all requests to token endpoint or
claims endpoint to mitigate session fixation and related attacks
(#239, #205)
As noted above, these are all filed as issues with the UMA working
group and all have been well documented to date. We built what we
thought would be the best solution to each of these issues in turn.
We’ve implemented all of these changes in a branch in our server that
we’re putting under the title “multiparty”, as in “multiparty
delegation protocol”. Since this isn’t compliant with UMA (in some
cases by design), these changes are not in our master branch nor in
our release stream at this time. But the code is still publicly
available:
We’ve also implemented a very, very simple client and a very, very
simple protected resource using the same changes above, as well as all
the “best practice” recommended changes in 1.0.1 that should probably
become requirements in future versions (such as returning the ticket
in a header from the resource):
You can run all three of these components together on a localhost
Tomcat instance to try them out. Speaking from my own personal
experience developing both this new code set and the original UMA
spec, I can say that I prefer this new version hands down. The code is
drastically simplified in a number of places, information flow is much
cleaner overall, and there’s less guesswork expected of components at
each step. The nature of some of these changes (like removal of the
AAT) make this new protocol immediately more applicable to a wide
ecosystem use case as well.
nynymike
commented
7 years ago
On 2016-03-19 04:31, Justin Richer wrote: