[keycloak-dev] Feedback

Pedro Igor Silva psilva at redhat.com
Mon Jun 20 12:08:26 EDT 2016 

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, June 20, 2016 3:50:26 AM
> Subject: Re: [keycloak-dev] Feedback
> 
> On 17/06/16 17:51, Pedro Igor Silva wrote:
> > Hey Marek,
> >
> >     First of all. Thanks for your questions. Answers inline.
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Pedro Igor Silva" <psilva at redhat.com>, "Bill Burke"
> >> <bburke at redhat.com>
> >> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Friday, June 17, 2016 11:30:39 AM
> >> Subject: Re: [keycloak-dev] Feedback
> >>
> >> I did not yet went deeply through all the details, however briefly went
> >> through the docs and examples. Few things:
> >>
> >> - Term "scope" seems to be overloaded as we have it in other places in
> >> Keycloak too? Now when you click to some Client and then to tab
> >> "Authorization" you can see 2 tabs "Scopes" (one in level1 and second in
> >> level2) but both are used for a bit different thing. Isn't it some
> >> better term like "Action" ? For example "john can do 'action' DELETE on
> >> photoalbum xyz" seems to me more intuitive than "john has 'scope' DELETE
> >> on photoalbum xyz" . Or is this term required by UMA specification?
> > This is the term adopted by UMA specification:
> >
> >     "A bounded extent of access that is possible to perform on a resource
> >     set. In authorization policy terminology, a scope is one of the
> >     potentially many "verbs" that can logically apply to a resource set
> >     ("object")."
> >
> > In UMA, the resources associated with a scope are not implicit, but
> > explicitly defined to a particular registered resource set.
> >
> > We can change it to something like "Actions". But I would prefer to stick
> > with the scope term somehow, maybe "Resource Scopes" instead of just
> > "Scopes" ?
> >
> > I think "Actions" is not a OAuth2/UMA-like terminology :)
> Ok, maybe "Resource Scopes" or "Authorization Scopes" is better then?
> Another possible thing is, that we should maybe also change the original
> meaning of "Scope" under client, which we use for limiting allowed 3rd
> party roles in the accessToken. I don't know TBH, maybe adding role
> namespaces will clearify this a bit...

OK, well'l change it to "Resource Scopes".

IMO, we should expand the concept of Keycloak Scopes. Currently, there is a 1:1 mapping between roles and scopes, but scopes are much more than role mapping.

It would be nice to build scopes from attributes or even compose a scope based on multiple attributes.  For instance, a "profile" attribute could be a scope that includes "email", "address", "first name", "last name" attributes. If a client is granted with this scope (based on user consent), these attributes would be available from the access token.

Or is that already supported and I'm missing it ? Maybe we should discuss that on a separated thread :)

> >
> >> - Is it possible to merge JSON file representation with the main
> >> keycloak RealmRepresentation? Currently to have "photoz" example
> >> running, I need to import realm ( photoz-uma-realm.json ) and then
> >> separately also another JSON with authorization configuration (
> >> photoz-uma-restful-api-authz.json ). If configuration of ResourceServer
> >> is moved under particular client of realm, it can be exported during
> >> export/import of whole realm and then imported again in single step. We
> >> can still support to import just the authorization configuration though,
> >> but have it supported when inside global file is good too IMO.
> > +1. Can we have that after 2.0.0.CR1 ?
> Sure, it's fine to add later IMO.

https://issues.jboss.org/browse/KEYCLOAK-3144

> >
> >> - Should be Time-Based Policy the "first-class-citizen" - one of builtin
> >> policies? It seems you can achieve the same with Rule based policies
> >> (Javascript or Drools) ? You can simulate some other simpler policies
> >> like role-based or attribute-based with rule policies too, however they
> >> will be likely much more common usecase.
> > IMO, it should be kept as a built-in policy type. We should not rely on
> > rule-based policies for everything.
> >
> > In fact, the idea is make policy mgmt easier. Ideally, we should have a lot
> > of built-in policy types.
> Ok. Just wonder if having many built-in policy types won't make things
> more complex rather than easier. Maybe if some newbie will first see the
> page with 20 builtin policy types, his first impression might be "Oh,
> there are so many policies... This authorization thing looks quite
> complex. I will rather hack something directly to my app, instead of
> learn all of those..."
> 
> But hopefully I am wrong :-)

I think complexity is not really related with the amount of OOTB and built-in policy types we provided. On the contrary, specific policy types will make life a lot easier for users. For instance, if your requirement says that only users from Brno (location) can access some stuff, we may provide a "Location-based" (group Context-Based) policy that provides a Google-map or some other input to specify a location.

I'm not saying that we should have a policy type for everything, but elect those that may be provided OOTB.

Regarding hacking authz directly into an app, people tend to follow the easiest path. That is pretty much what we (devs) have been doing it for years. However, I strongly believe that this practice is changing, specially if you consider cloud security, IoT and what people call micro services.

In fact, we are starting to see use-cases/specifications like UMA and this one [1] which are already considering fine-grained authz as a first-class citizen. There is also XACML, which is still alive and have its space in enterprises.

I hope we could provide something easy for the most simple to the more complex use cases, where using KC as a centralized authorization server won't be too much different and harder than hack authz directly to your app :)

[1] https://tools.ietf.org/html/draft-seitz-ace-usecases-01

> >
> >> - Java AuthzClient seems to be directly using Apache HttpClient. Is it
> >> easier to have it as jax-rs (or resteasy) client similarly like our
> >> admin-client? Or you want to avoid another dependency? It seems we
> >> currently have 3 clients (admin-client , client-registration , authz),
> >> so maybe we can somehow unify them to use similar approach and we can
> >> remove some boilerplate code? But this is implementation detail though...
> > I was using resteasy client, the reasons for dropping it was:
> >
> > * adapter-core is using http client
> > * more flexibility to support an async API. Useful for reactive apps, MSAD,
> > etc
> >
> > If you look at the client API, I have added a very simple indirection layer
> > to integrate with a third-party http client library.
> >
> >> - Is it possible to see the list of available context attributes of
> >> javascript (or drools) policy? Also it's maybe possible to simplify
> >> names? For example 'kc.authz.context.client.network.ip_address' is quite
> >> a long name knowing that this is something, which people will be using
> >> in their impl?
> > +1
> >
> > My main requirement regarding the name is that it should represent what is
> > the attribute and its context. Maybe 'kc.authz.context' is redundant ? So
> > we may have 'client.network.ip' ?
> >
> > I've documented some of these attributes [1]. I think I need to improve the
> > doc to highlight them. Will provide a specific topic and a table with all
> > supported attributes.
> Thanks. Maybe "client.network.ip" or "kc.client.ip" (just keep "kc"
> prefix for all attributes provided by keycloak) is easier?

+1

> 
> Btv. just noticed that 2 links from javascript policy page
> https://keycloak.gitbooks.io/authorization-services-guide/content/topics/policy/js-policy.html
> to "Evaluation API" are broken.
> >
> >> - During the call few months ago, I mentioned the "weight" of
> >> authorization decision of aggregation policy. I want to cancel that as
> >> it looks you can always achieve the same effect by compose more
> >> aggregate policies together, so weight is not needed though. So this is
> >> just un-feedback of my previous feedback :)
> >>
> >> - Is it possible to dynamically create permissions with Permissions API?
> >> Looks like just creating resources is possible ATM? For example, I
> >> wonder about classic social usecase "I want to share my photoalbum with
> >> user X" . Or "I want to share my photoalbum with group of users Y
> >> (Google+ circles)" . I guess UMA specs might have some support for this?
> > +1
> >
> > UMA does not provide an API for that. That Permission API is for permission
> > tickets only (UMA thing).
> >
> > At the beginning, I have published the policy endpoint for remote access
> > and an "Allow Remote Policy Management" button on the "Authorization
> > Settings" page. I have removed it to think about this stuff with a little
> > more love. We can do something really awesome with that.
> >
> > I'm glad that you found it useful too, I hope to start a separated
> > discussion to understand better your ideas around this topic.
> >
> > https://issues.jboss.org/browse/KEYCLOAK-3135
> Ok, I will add comments to JIRA
> 
> Marek
> >
> >> - After create new photoalbum in the application, I can see that one new
> >> session is always created (tabs "Sessions" under client). When I delete
> >> photoalbum, I can see 6 (!!!) new sessions created. After create and
> >> delete few albums, I can see 44 active sessions :) I didn't verify what
> >> happens, looks like quite a lot of resource-owner-password-credentials
> >> or client-credentials requests? But seems we have time for optimizations
> >> and polishing later though...
> > Oops ! Will check that right away !
> >
> >> Marek
> >>
> >> On 16/06/16 19:12, Pedro Igor Silva wrote:
> >>> 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
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
>

More information about the keycloak-dev mailing list