[keycloak-dev] Feedback
Pedro Igor Silva
psilva at redhat.com
Fri Jun 17 11:51:35 EDT 2016
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 :)
>
> - 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 ?
>
> - 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.
>
> - 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.
>
> - 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
>
> - 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