10:55 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: "keycloak-dev" <keycloak-dev(a)lists.jboss.org>
Sent: Friday, June 10, 2016 12:43:51 PM
Subject: Re: Feedback
On 6/10/16 11:23 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: "Pedro Igor Silva" <psilva(a)redhat.com>
>> Cc: "keycloak-dev" <keycloak-dev(a)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(a)redhat.com>
>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com>
>>>> Cc: "keycloak-dev" <keycloak-dev(a)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
+1. And that is the reason why I'm following this path now. So far, I was using a very
specific token to hold authz data. But as you said, let's discuss about performance
and optimizations at the appropriate time and release this stuff first. We can do a lot of
things at this regard.
Regarding token size, during this work I did a research about this topic and there are
interesting discussions on OAuth2-WG.
Thanks for all feedback, it was really important to improve things.