Hey Marek,
First of all. Thanks for your questions. Answers inline.
----- Original Message -----
From: "Marek Posolda" <mposolda(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>, "Bill Burke"
<bburke(a)redhat.com>
Cc: "keycloak-dev" <keycloak-dev(a)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/...
>
>
> ----- Original Message -----
> From: "Pedro Igor Silva" <psilva(a)redhat.com>
> To: "Bill Burke" <bburke(a)redhat.com>
> Cc: "keycloak-dev" <keycloak-dev(a)lists.jboss.org>
> Sent: Friday, June 10, 2016 12:55:39 PM
> Subject: Re: [keycloak-dev] Feedback
>
> ----- 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 12:43:51 PM
>> Subject: Re: Feedback
>>
>>
>>
>> On 6/10/16 11:23 AM, Pedro Igor Silva wrote:
>>> ----- 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 12:11:37 PM
>>>> Subject: Re: Feedback
>>>>
>>>>
>>>>
>>>> On 6/10/16 10:59 AM, Pedro Igor Silva wrote:
>>>>> ----- 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.
>>>> 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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev