[keycloak-dev] Feedback

[Bill Burke]

On 6/10/16 11:23 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>> Sent: Friday, June 10, 2016 12:11:37 PM
>> Subject: Re: Feedback
>>
>>
>>
>> On 6/10/16 10:59 AM, Pedro Igor Silva wrote:
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Friday, June 10, 2016 10:39:07 AM
>>>> Subject: Re: Feedback
>>>>
>>>>
>>>>
>>>> On 6/9/16 11:04 PM, Pedro Igor Silva wrote:
>>>>> Bill,
>>>>>
>>>>> Got the authz stuff working with the adapters. It was a puzzle but I
>>>>> think
>>>>> I have something.
>>>> Yeah, its nasty.  Every servlet container handlers security just a bit
>>>> differently than others so, its ugly.
>>>>
>>>>> * I've discarded my own sub-types of AccessToken, they were redundant.
>>>>> The
>>>>> only difference between authz tokens and access tokens was a list of
>>>>> permissions. And the concept behind them is the same. I've added a
>>>>> "authorization" claim to AccessToken (null by default) from where
>>>>> permissions granted by the server can be obtained.
>>>> Is a claim better?
>>> To represent a RPT, I believe it is.
>>>
>>>> Or should AccessTokenResponse optionally contain the RPT?
>>> IMO, that would make things harder from a client perspective. See my next
>>> comments.
>>>
>>>> Or optionally a query param for Implicit Flow?  Or have both?  I
>>>> don't know.
>>> I think we have two different things here:
>>>
>>> * How a RPT looks like
>>> * How a RPT is obtained (the protocol in use)
>>>
>>> In the first case, a RPT is just a special type of access token with
>>> authorization data on it. Where this data is a result of the evaluation of
>>> permissions and authorization policies associated with the resources being
>>> requested. Here, that claim represents this data. This is protocol
>>> agnostic.
>>>
>>> The latter case is how you obtain that data, which is strongly associated
>>> with the protocol in use. What you said makes a lot of sense, we can issue
>>> this authorization data when doing any of the OAuth2 grant types. That can
>>> be specially useful when you want to obtain all permissions for an user at
>>> once when authenticating in KC, avoiding an additional call to the server
>>> in order to obtain authorization specific data. One way to achieve that
>>> would be a
>>> "Entitlement Protocol Mapper" that is capable of decorating an access token
>>> with the authorization data. Thus, transforming the access token into a
>>> RPT. See, the client just use the final access token without any
>>> additional treatment.
>>>
>>> There are a lot of other features to implement around both UMA and
>>> Entitlement protocols. For instance, claims gathering or obligations. So
>>> the server can ask the client for additional information. Eg.: require a
>>> higher security level, etc. And for that, we must be able to obtain authz
>>> data separately.
>> IIRC, there's a REST API right that allows a client to turn an access
>> token into an RPT?
> Yes, that is what both Authorization and Entitlement API are meant for.
>
>> So, if Client A gets an access token, it can invoke
>> on Service B.  Service B can pass the access token to Keycloak to obtain
>> an RPT?
> Yes you can. The built-in policy enforcers (related with the changes I did to adapters) can operation in two modes:
>
> * Bearer Token
> * "Stateful" scenario (eg.: monolithic JEE apps)
>
> In the first case, is up to the client to obtain and send the RPT with the necessary permissions to access protected resources on the resource server(Service B). Here you can use two protocols: UMA and Entitlement. You know UMA. Entitlement is just a more lightweight and 1-legged protocol based on some UMA concepts. It doesn't require permission tickets and stuff.
>
> In the latter case, there is a specific policy enforcer that does exactly what you described. Obtaining a RPT transparently from a Keycloak server using the *Entitlement* API.
>
My only reasoning for wanting the option to include the RPT in the 
AccessTokenResponse was for performance reasons.  Obtaining an RPT could 
be obtained for free for a specific client by piggybacking on the OAuth 
protocol, but the access token could remain small/lightweight and not 
contain the RPT.  You'd still want to be able to include the RPT within 
the AT if so desired, but there might come a point when the AT becomes 
too fat.

All this isn't really important at this time though.  What's more 
important is releasing Authz soon.  I just foresese us wanting to 
provide different optimizations for different environments.

Bill