[keycloak-dev] Non-UMA Use Cases

[Pedro Igor Silva]

On Thu, Mar 1, 2018 at 2:06 PM, Anil Saldanha <asaldanha1947 at gmail.com>
wrote:

> 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
>

Indeed, they have different audiences ....

Although is perfectly fine to use UMA in all these use cases, IMO.

The main reason behind the Entitlement API is provide a (UMA-1)-legged
protocol for obtaining permissions.


>
>
> 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
>>
>
>