6:06 p.m.
Also Entitlements API is useful in cloud environments or API based billing environments -
- you want to minimize the number of calls you make to decide on an access check.
This may be different from UMA usecases
On Mar 1, 2018, at 10:27 AM, Anil Saldanha
<asaldanha1947(a)gmail.com> wrote:
Pedro,
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. :-)
UMA is focused on User managed attributes and privacy controls.
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.
If the Entitlements API usage by users/applications is very very low, just drop it and
start using the new UMA grant type.
Regards,
Anil
> On Wed, Feb 28, 2018 at 1:25 PM, Pedro Igor Silva <psilva(a)redhat.com> wrote:
> Hi,
>
> There are situations where you don't want to use the UMA protocol to obtain
> permissions from the server in form of an access token. Reasons can be: you
> 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 resources
> and scopes you want to get access and get back the access token with these
> permissions.
>
> This is what we provide today with the Entitlement API, an alternative that
> 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 [1] for obtaining permissions from the server using the token
> endpoint. Just like any other OAuth2 grant type, the UMA grant type expects
> 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 functionality
> to this new grant type makes sense and if, maybe, we should have a specific
> grant type (based on UMA grant type) that allows authorization requests
> without a permission ticket (but a list of resources and scopes you want to
> access). As side note, the code for UMA and non-UMA authorization is pretty
> much the same, the main difference is on the format of the authorization
> request/protocol.
>
> [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev