[keycloak-dev] Feedback

Thu Jun 16 13:12:36 EDT 2016

Hi All,

   After reviewing somethings based on the feedback from Bill and Stian, I've updated both code and docs [1] to reflect what we have discussed.

   In a nutshell, I think UX is much better now. With less steps to get things done and in some cases with a default configuration to quickly get started with authorization services.

   Special attention to the "Managing Resource Server" [2] section. There you'll understand the main changes that made things more simple.

   I'll be working with some getting started tutorials, I think they will be very simple and easy to follow now.

   Please, let me know your thoughts.

[1] https://keycloak.gitbooks.io/authorization-services-guide/content/
[2] https://keycloak.gitbooks.io/authorization-services-guide/content/topics/resource-server/overview.html

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "Bill Burke" <bburke at redhat.com>
Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
Sent: Friday, June 10, 2016 12:55:39 PM
Subject: Re: [keycloak-dev] Feedback

----- 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:43:51 PM
> Subject: Re: Feedback
> 
> 
> 
> 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

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

> 
> 
> 
> 
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev