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