[keycloak-dev] Feedback

[Pedro Igor Silva]

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

> 
> 
>