[keycloak-dev] Feedback

Fri Jun 17 10:30:39 EDT 2016

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?

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

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

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

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

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

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

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