[keycloak-dev] Non-UMA Use Cases

[Pedro Igor Silva]

Yeah ... that is a reality.

Authorization is not easy. At least if you think beyond simple RBAC. But I
think things are changing, authorization requirements are becoming more
complex (including now privacy), with all this cloud native stuff and
everything being externalized from apps ...

A lot of challenges ....

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

> Authorization is pretty hard for people to wrap their heads around.  Now
> if you try to push the UMA dance (however good it is) as the holy grail for
> all your authorization needs, it may make things more confusing.  That is
> why people just stick to authentication and passwords because everything
> else is hard. :)
>
> On Thu, Mar 1, 2018 at 11:24 AM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> Hey Anil !
>>
>> I appreciate the feedback.
>>
>> On Thu, Mar 1, 2018 at 1:27 PM, 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. :-)
>>>
>>
>> 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
>> "urn:ietf:params:oauth:grant-type:kc-entitlement".
>>
>> 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 :)
>>
>>
>>>
>>> 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
>>>>
>>>
>>>
>>
>