Hey Anil !
I appreciate the feedback.
On Thu, Mar 1, 2018 at 1:27 PM, Anil Saldanha <asaldanha1947(a)gmail.com>
my personal opinion here.
The goal of the Entitlements API is to use for contextual authorization.
It does not just rely on user attributes including privacy. There are
other aspects to the context - resource attributes, environmental
attributes, channel attributes etc. :-)
In addition to that, we try to provide a more lightweight protocol for
obtaining permissions from the server.
UMA is focused on User managed attributes and privacy controls.
True but with UMA it should also be possible to push contextual data,
considering that the resource server is responsible to create permission
tickets and put whatever data they want there. So we can use these same
data later when evaluating policies. In Keycloak permission tickets are not
persisted and are short-lived. Of course, depending on the "contextual"
data you have in a permission ticket more quickly you need use it.
Otherwise you may evaluate policies with stale data.
While you are trying to unify the api into one under the UMA endpoint
umbrella, I feel that it may be better to keep them separate.
I'm not really trying to "unify" both approaches, you know. But have the
Entitlement API also working using the standard OAuth2 Token Endpoint,
which a specific grant type. Like I said, right now I'm reusing
"urn:ietf:params:oauth:grant-type:uma-ticket" but I'm inclined to define a
specific grant type for the "entitlement api", something like
In a nutshell, the "unification" here is basically an alignment with OAuth2
standard. An extension/custom grant type.
If the Entitlements API usage by users/applications is very very low, just
drop it and start using the new UMA grant type.
My feeling is that Entitlement API usage is higher than UMA. I think the
main reason for that is that people is not yet (but I believe more and more
privacy will be a first-class concern to apps and services) concerned about
privacy. But security ... and how to protect APIs and application resources.
I have seen people get really confused about the UMA dance ... But that is
until they understand all motivations and the beauty behind it :)
On Wed, Feb 28, 2018 at 1:25 PM, Pedro Igor Silva <psilva(a)redhat.com>
> There are situations where you don't want to use the UMA protocol to
> permissions from the server in form of an access token. Reasons can be:
> don't have any privacy requirements or your requirements don't require all
> the UMA dance to obtain an access token.
> In these situations, you may just want to send a request with the
> and scopes you want to get access and get back the access token with these
> This is what we provide today with the Entitlement API, an alternative
> simplifies how clients can obtain permissions from the server.
> However, with the introduction of UMA 2.0 support, we have now a specific
> grant type  for obtaining permissions from the server using the token
> endpoint. Just like any other OAuth2 grant type, the UMA grant type
> a HTTP FORM request with some parameters.
> The Entitlement API no longer exists but the same behavior can be achieved
> with the new UMA grant type that was introduced. In other words, you can
> use this grant type to ask for an access token with permissions without
> sending a permission ticket but a list of resources/scopes (as parameters)
> you want to get access.
> The reason for reusing the grant type is that I would like to avoid having
> two endpoints for obtaining permissions from the server. I think it makes
> things simple.
> Would like to know your opinion if moving the Entitlement API
> to this new grant type makes sense and if, maybe, we should have a
> grant type (based on UMA grant type) that allows authorization requests
> without a permission ticket (but a list of resources and scopes you want
> access). As side note, the code for UMA and non-UMA authorization is
> much the same, the main difference is on the format of the authorization
>  https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html
> Pedro Igor
> keycloak-dev mailing list