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