[keycloak-dev] Non-UMA Use Cases

[Anil Saldanha]

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 at 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>