10:23 a.m.
Hi All,
Asked Bill for some feedback about AuthZ docs [1] and would like to share with you.
@Bill, my initial comments inline.
[1] https://keycloak.gitbooks.io/authorization-services-guide/content/
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Sent: Wednesday, June 8, 2016 11:15:03 AM
Subject: Re: Feedback
* Example is too complex. Needs to be broken down and explained for
each policy that was created.
OK. By "broken down" you mean using sub-topics (pages) or just sections on the
same page ?
The "Hello World" one should be fine because it is just a single policy example.
The "Securing a Servlet Application" may have more details about each of those
policies, will work on that. Or even just point to their respective documentation, as we
also have doc for each policy type.
* Example should not use JSON import. It should walk through screen
shots to explain how to set up things.
The idea behind using JSON import is that it provides an easy and fast way to users get
started. After all, you just need to copy&paste configuration (or obtain from examples
dir) and import to KC. IMO, that makes the tutorial more easy to follow with focus on the
main concepts being explained.
I'm trying to keep documentation about UI on each topic, so you can see how to use
admin console to create/configure things.
* Need more screenshots throughout doc
Probably related with your previous feedback. I'm going to take some more screenshots
....
* Is Resource Server->Client always a one-to-one thing?
No, RS<->Client is not always a 1:1 mapping. Usually, they would be different
entities, where the client is acting on behalf of the RO to access protected resources on
a resource server. That is true for most API security use cases.
However, an app may use both hats. For instance, monolithic JEE apps.
Maybe Authorization should move under clients tab?
That is a good question. And my quick answer for that would be to keep it separated for
now.
I think changes like that may involve more discussions around UI design. For instance,
today clients and resource servers are managed in the same space (Clients in left menu
bar). As you know, clients (entities accessing a RS on behalf of an user) and RSs are
different things and although they share a lot of things, I think we could have have them
*visually* separated somehow.
AuthZ includes more tabs and flows, so I don't think move under clients tab would be a
good idea. I'm not a UX expert, there is probably a way to do what you want nicely
...
* Looks like there is a bit of redundant config for adapters. How big is
authz at the adapter side?
From an adapter perspective, AuthZ code is pretty much straightforward
and small. The redundant config you are talking about is probably the "client"
property in keycloak-authz.json. So yes, it is.
Today, authz code is basically provided by a Servlet Filter. See Policy Enforcers.
Maybe this code should be merged with our
adapters so config for user becomes simpler?
Well, I was trying to avoid change adapters. At least for now.
We can get those changes merged with our OIDC adapters, for sure. So I could move that
*enforcer* property to a keycloak.json file.
The question is if we should just leave that way for now and release this stuff. It is
your call, if you want them merged I'll do it.
Something to think about
and look into. Really probably depends how many dependencies authz
brings in.
There is no additional deps ...
* Need to unify scripting and SPI objects. Authz should share SPI
objects (i.e. client IP address) with AuthenticationFlow SPI and other
things. Looks like you might have duplicate things.
Saw that you merged some scripting stuff to authentication flow recently. But I'm not
sure about have both authc and authz sharing the same SPI right now.
I don't think I'm replicating things. We are basically exposing a Evaluation API
(that should be as simple as possible) that users can use to build rule-based policyes
(eg.: JS, Drools, etc). Here are basically ABAC and policies can obtain
information using both identities and environment/runtime attributes.
For instance, whatever you put in a access token (eg.: using a protocol mapper) would be
available as an attribute. Thus, available to policies.
On 6/7/16 4:40 PM, Pedro Igor Silva wrote:
> Hey Bill !
>
> When you get some time, could you please take a quick look at
> https://keycloak.gitbooks.io/authorization-services-guide/content/index.html.
>
> There you will find the documentation for AuthZ Services and what I've
> documented so far.
>
> Your feedback is really appreciated :)
>
> Thanks.
> Pedro Igor
1:25 p.m.
New subject: Feedback
On 6/8/16 11:23 AM, Pedro Igor Silva wrote:
Hi All,
Asked Bill for some feedback about AuthZ docs [1] and would like to share with you.
@Bill, my initial comments inline.
[1] https://keycloak.gitbooks.io/authorization-services-guide/content/
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Pedro Igor Silva" <psilva(a)redhat.com>
> Sent: Wednesday, June 8, 2016 11:15:03 AM
> Subject: Re: Feedback
>
> * Example is too complex. Needs to be broken down and explained for
> each policy that was created.
OK. By "broken down" you mean using sub-topics (pages) or just sections on the
same page ?
The "Hello World" one should be fine because it is just a single policy
example. The "Securing a Servlet Application" may have more details about each
of those policies, will work on that. Or even just point to their respective
documentation, as we also have doc for each policy type.
> * Example should not use JSON import. It should walk through screen
> shots to explain how to set up things.
The idea behind using JSON import is that it provides an easy and fast way to users get
started. After all, you just need to copy&paste configuration (or obtain from examples
dir) and import to KC. IMO, that makes the tutorial more easy to follow with focus on the
main concepts being explained.
JSON is great for running an example, but not great
for documentation.
I'm trying to keep documentation about UI on each topic, so you
can see how to use admin console to create/configure things.
> * Need more screenshots throughout doc
Probably related with your previous feedback. I'm going to take some more screenshots
....
> * Is Resource Server->Client always a one-to-one thing?
No, RS<->Client is not always a 1:1 mapping. Usually, they would be different
entities, where the client is acting on behalf of the RO to access protected resources on
a resource server. That is true for most API security use cases.
However, an app may use both hats. For instance, monolithic JEE apps.
> Maybe Authorization should move under clients tab?
That is a good question. And my quick answer for that would be to keep it separated for
now.
I think changes like that may involve more discussions around UI design. For instance,
today clients and resource servers are managed in the same space (Clients in left menu
bar). As you know, clients (entities accessing a RS on behalf of an user) and RSs are
different things and although they share a lot of things, I think we could have have them
*visually* separated somehow.
AuthZ includes more tabs and flows, so I don't think move under clients tab would be
a good idea. I'm not a UX expert, there is probably a way to do what you want nicely
...
Maybe Resource Server is a misleading name? Maybe it should be named a
Resource Manager or Resource Catalogue? What about having a Resources
tab under Client that lists the "Resource Servers" attached to the
client and the ability to add/remove Resource Servers for that client?
Its just a different way to navigate.
> * Looks like there is a bit of redundant config for adapters. How
big is
> authz at the adapter side?
From an adapter perspective, AuthZ code is pretty much straightforward and small. The
redundant config you are talking about is probably the "client" property in
keycloak-authz.json. So yes, it is.
Today, authz code is basically provided by a Servlet Filter. See Policy Enforcers.
OIDC adapter provides:
* client id
* realm name
* realm public key
* auth server URL
I'm pretty sure the adapter config could be made available to the authz
adapter. It would allow you to reduce the number of steps to configure
this stuff.
> Maybe this code should be merged with our
> adapters so config for user becomes simpler?
Well, I was trying to avoid change adapters. At least for now.
We can get those changes merged with our OIDC adapters, for sure. So I could move that
*enforcer* property to a keycloak.json file.
The question is if we should just leave that way for now and release this stuff. It is
your call, if you want them merged I'll do it.
Across the board, for all of Keycloak, we need to put some thought into
how to make things easier to configure with intuitive defaults, etc.
For example, there has been some talk of having ZERO config at the
adapter side except the realm URL and a client token. Apps would then
pull down all of their configuration from Keycloak.
> Something to think about
> and look into. Really probably depends how many dependencies authz
> brings in.
There is no additional deps ...
> * Need to unify scripting and SPI objects. Authz should share SPI
> objects (i.e. client IP address) with AuthenticationFlow SPI and other
> things. Looks like you might have duplicate things.
Saw that you merged some scripting stuff to authentication flow recently. But I'm not
sure about have both authc and authz sharing the same SPI right now.
I don't think I'm replicating things.
You are at least replicating access
to Client IP address. We need to
make sure that the variable names and variable references are consistent
between Authentication Flow scripting and Authz Scripting. We can't
have a completely different dictionary.
2:12 p.m.
New subject: Feedback
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>, "keycloak-dev"
<keycloak-dev(a)lists.jboss.org>
Sent: Wednesday, June 8, 2016 3:25:53 PM
Subject: Re: Feedback
On 6/8/16 11:23 AM, Pedro Igor Silva wrote:
> Hi All,
>
> Asked Bill for some feedback about AuthZ docs [1] and would like to share
> with you.
>
> @Bill, my initial comments inline.
>
> [1] https://keycloak.gitbooks.io/authorization-services-guide/content/
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: "Pedro Igor Silva" <psilva(a)redhat.com>
>> Sent: Wednesday, June 8, 2016 11:15:03 AM
>> Subject: Re: Feedback
>>
>> * Example is too complex. Needs to be broken down and explained for
>> each policy that was created.
> OK. By "broken down" you mean using sub-topics (pages) or just sections
on
> the same page ?
>
> The "Hello World" one should be fine because it is just a single policy
> example. The "Securing a Servlet Application" may have more details about
> each of those policies, will work on that. Or even just point to their
> respective documentation, as we also have doc for each policy type.
>
>> * Example should not use JSON import. It should walk through screen
>> shots to explain how to set up things.
> The idea behind using JSON import is that it provides an easy and fast way
> to users get started. After all, you just need to copy&paste configuration
> (or obtain from examples dir) and import to KC. IMO, that makes the
> tutorial more easy to follow with focus on the main concepts being
> explained.
JSON is great for running an example, but not great for documentation.
OK. Changing ...
> I'm trying to keep documentation about UI on each topic, so you can see how
> to use admin console to create/configure things.
>
>> * Need more screenshots throughout doc
> Probably related with your previous feedback. I'm going to take some more
> screenshots ....
>
>> * Is Resource Server->Client always a one-to-one thing?
> No, RS<->Client is not always a 1:1 mapping. Usually, they would be
> different entities, where the client is acting on behalf of the RO to
> access protected resources on a resource server. That is true for most API
> security use cases.
>
> However, an app may use both hats. For instance, monolithic JEE apps.
>
>> Maybe Authorization should move under clients tab?
> That is a good question. And my quick answer for that would be to keep it
> separated for now.
>
> I think changes like that may involve more discussions around UI design.
> For instance, today clients and resource servers are managed in the same
> space (Clients in left menu bar). As you know, clients (entities accessing
> a RS on behalf of an user) and RSs are different things and although they
> share a lot of things, I think we could have have them *visually*
> separated somehow.
>
> AuthZ includes more tabs and flows, so I don't think move under clients tab
> would be a good idea. I'm not a UX expert, there is probably a way to do
> what you want nicely ...
Maybe Resource Server is a misleading name? Maybe it should be named a
Resource Manager or Resource Catalogue? What about having a Resources
tab under Client that lists the "Resource Servers" attached to the
client and the ability to add/remove Resource Servers for that client?
Its just a different way to navigate.
Don't think Resource Server is a misleading name. It is a pretty well concept on
OAuth2 world.
Maybe I can give a shot to your suggestion and move all AuthZ UIs to a "Resource
Server" tab. Or even have all those AuthZ UI tabs as separated tabs. Will send you
screenshots with the result.
[NOTE]
I think I misunderstood your original question about the 1:1 mapping between RS and
Clients. My answer was based on a conceptual view of those entities, where RS and Client
may represent or not the same entity.
From a implementation view, RS and Client have 1:1 mapping.
>> * Looks like there is a bit of redundant config for adapters. How big is
>> authz at the adapter side?
> From an adapter perspective, AuthZ code is pretty much straightforward and
> small. The redundant config you are talking about is probably the
> "client" property in keycloak-authz.json. So yes, it is.
>
> Today, authz code is basically provided by a Servlet Filter. See Policy
> Enforcers.
OIDC adapter provides:
* client id
* realm name
* realm public key
* auth server URL
I'm pretty sure the adapter config could be made available to the authz
adapter. It would allow you to reduce the number of steps to configure
this stuff.
OK
>> Maybe this code should be merged with our
>> adapters so config for user becomes simpler?
> Well, I was trying to avoid change adapters. At least for now.
>
> We can get those changes merged with our OIDC adapters, for sure. So I
> could move that *enforcer* property to a keycloak.json file.
>
> The question is if we should just leave that way for now and release this
> stuff. It is your call, if you want them merged I'll do it.
Across the board, for all of Keycloak, we need to put some thought into
how to make things easier to configure with intuitive defaults, etc.
For example, there has been some talk of having ZERO config at the
adapter side except the realm URL and a client token. Apps would then
pull down all of their configuration from Keycloak.
See, config is already minimal. Beside the keycloak-authz.json we discussed, you just need
to change web.xml and jboss-deployment-structure.xml. The first is a necessary evil, but I
can remove the latter.
>> Something to think about
>> and look into. Really probably depends how many dependencies authz
>> brings in.
> There is no additional deps ...
>
>> * Need to unify scripting and SPI objects. Authz should share SPI
>> objects (i.e. client IP address) with AuthenticationFlow SPI and other
>> things. Looks like you might have duplicate things.
> Saw that you merged some scripting stuff to authentication flow recently.
> But I'm not sure about have both authc and authz sharing the same SPI
> right now.
>
> I don't think I'm replicating things.
You are at least replicating access to Client IP address. We need to
make sure that the variable names and variable references are consistent
between Authentication Flow scripting and Authz Scripting. We can't
have a completely different dictionary.
I agree. Do you mind if we postpone that to a second release ? So I can take a better look
on that new scripting SPI and see how we can use it here ?
2:29 p.m.
New subject: Feedback
On 6/8/16 3:12 PM, Pedro Igor Silva wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Pedro Igor Silva" <psilva(a)redhat.com>, "keycloak-dev"
<keycloak-dev(a)lists.jboss.org>
> Sent: Wednesday, June 8, 2016 3:25:53 PM
> Subject: Re: Feedback
>
>
>
> On 6/8/16 11:23 AM, Pedro Igor Silva wrote:
>> Hi All,
>>
>> Asked Bill for some feedback about AuthZ docs [1] and would like to share
>> with you.
>>
>> @Bill, my initial comments inline.
>>
>> [1] https://keycloak.gitbooks.io/authorization-services-guide/content/
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke(a)redhat.com>
>>> To: "Pedro Igor Silva" <psilva(a)redhat.com>
>>> Sent: Wednesday, June 8, 2016 11:15:03 AM
>>> Subject: Re: Feedback
>>>
>>> * Example is too complex. Needs to be broken down and explained for
>>> each policy that was created.
>> OK. By "broken down" you mean using sub-topics (pages) or just sections
on
>> the same page ?
>>
>> The "Hello World" one should be fine because it is just a single
policy
>> example. The "Securing a Servlet Application" may have more details
about
>> each of those policies, will work on that. Or even just point to their
>> respective documentation, as we also have doc for each policy type.
>>
>>> * Example should not use JSON import. It should walk through screen
>>> shots to explain how to set up things.
>> The idea behind using JSON import is that it provides an easy and fast way
>> to users get started. After all, you just need to copy&paste configuration
>> (or obtain from examples dir) and import to KC. IMO, that makes the
>> tutorial more easy to follow with focus on the main concepts being
>> explained.
> JSON is great for running an example, but not great for documentation.
OK. Changing ...
>> I'm trying to keep documentation about UI on each topic, so you can see how
>> to use admin console to create/configure things.
>>
>>> * Need more screenshots throughout doc
>> Probably related with your previous feedback. I'm going to take some more
>> screenshots ....
>>
>>> * Is Resource Server->Client always a one-to-one thing?
>> No, RS<->Client is not always a 1:1 mapping. Usually, they would be
>> different entities, where the client is acting on behalf of the RO to
>> access protected resources on a resource server. That is true for most API
>> security use cases.
>>
>> However, an app may use both hats. For instance, monolithic JEE apps.
>>
>>> Maybe Authorization should move under clients tab?
>> That is a good question. And my quick answer for that would be to keep it
>> separated for now.
>>
>> I think changes like that may involve more discussions around UI design.
>> For instance, today clients and resource servers are managed in the same
>> space (Clients in left menu bar). As you know, clients (entities accessing
>> a RS on behalf of an user) and RSs are different things and although they
>> share a lot of things, I think we could have have them *visually*
>> separated somehow.
>>
>> AuthZ includes more tabs and flows, so I don't think move under clients tab
>> would be a good idea. I'm not a UX expert, there is probably a way to do
>> what you want nicely ...
> Maybe Resource Server is a misleading name? Maybe it should be named a
> Resource Manager or Resource Catalogue? What about having a Resources
> tab under Client that lists the "Resource Servers" attached to the
> client and the ability to add/remove Resource Servers for that client?
> Its just a different way to navigate.
Don't think Resource Server is a misleading name. It is a pretty well concept on
OAuth2 world.
Maybe I can give a shot to your suggestion and move all AuthZ UIs to a "Resource
Server" tab. Or even have all those AuthZ UI tabs as separated tabs. Will send you
screenshots with the result.
[NOTE]
I think I misunderstood your original question about the 1:1 mapping between RS and
Clients. My answer was based on a conceptual view of those entities, where RS and Client
may represent or not the same entity.
From a implementation view, RS and Client have 1:1 mapping.
A Client can be associated with more than one Resource Server?
> Across the board, for all of Keycloak, we need to put some thought into
> how to make things easier to configure with intuitive defaults, etc.
> For example, there has been some talk of having ZERO config at the
> adapter side except the realm URL and a client token. Apps would then
> pull down all of their configuration from Keycloak.
See, config is already minimal. Beside the keycloak-authz.json we discussed, you just
need to change web.xml and jboss-deployment-structure.xml. The first is a necessary evil,
but I can remove the latter.
Seems like if its all built into the same adapter, then there's a lot
less configuration steps
All this doesn't need to be done for first release. I'm just giving
feedback :)
2:34 p.m.
New subject: 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: Wednesday, June 8, 2016 4:29:42 PM
Subject: Re: Feedback
On 6/8/16 3:12 PM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: "Pedro Igor Silva" <psilva(a)redhat.com>,
"keycloak-dev"
>> <keycloak-dev(a)lists.jboss.org>
>> Sent: Wednesday, June 8, 2016 3:25:53 PM
>> Subject: Re: Feedback
>>
>>
>>
>> On 6/8/16 11:23 AM, Pedro Igor Silva wrote:
>>> Hi All,
>>>
>>> Asked Bill for some feedback about AuthZ docs [1] and would like to share
>>> with you.
>>>
>>> @Bill, my initial comments inline.
>>>
>>> [1] https://keycloak.gitbooks.io/authorization-services-guide/content/
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke(a)redhat.com>
>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com>
>>>> Sent: Wednesday, June 8, 2016 11:15:03 AM
>>>> Subject: Re: Feedback
>>>>
>>>> * Example is too complex. Needs to be broken down and explained for
>>>> each policy that was created.
>>> OK. By "broken down" you mean using sub-topics (pages) or just
sections
>>> on
>>> the same page ?
>>>
>>> The "Hello World" one should be fine because it is just a single
policy
>>> example. The "Securing a Servlet Application" may have more
details about
>>> each of those policies, will work on that. Or even just point to their
>>> respective documentation, as we also have doc for each policy type.
>>>
>>>> * Example should not use JSON import. It should walk through screen
>>>> shots to explain how to set up things.
>>> The idea behind using JSON import is that it provides an easy and fast
>>> way
>>> to users get started. After all, you just need to copy&paste
>>> configuration
>>> (or obtain from examples dir) and import to KC. IMO, that makes the
>>> tutorial more easy to follow with focus on the main concepts being
>>> explained.
>> JSON is great for running an example, but not great for documentation.
> OK. Changing ...
>
>>> I'm trying to keep documentation about UI on each topic, so you can see
>>> how
>>> to use admin console to create/configure things.
>>>
>>>> * Need more screenshots throughout doc
>>> Probably related with your previous feedback. I'm going to take some
more
>>> screenshots ....
>>>
>>>> * Is Resource Server->Client always a one-to-one thing?
>>> No, RS<->Client is not always a 1:1 mapping. Usually, they would be
>>> different entities, where the client is acting on behalf of the RO to
>>> access protected resources on a resource server. That is true for most
>>> API
>>> security use cases.
>>>
>>> However, an app may use both hats. For instance, monolithic JEE apps.
>>>
>>>> Maybe Authorization should move under clients tab?
>>> That is a good question. And my quick answer for that would be to keep it
>>> separated for now.
>>>
>>> I think changes like that may involve more discussions around UI design.
>>> For instance, today clients and resource servers are managed in the same
>>> space (Clients in left menu bar). As you know, clients (entities
>>> accessing
>>> a RS on behalf of an user) and RSs are different things and although they
>>> share a lot of things, I think we could have have them *visually*
>>> separated somehow.
>>>
>>> AuthZ includes more tabs and flows, so I don't think move under clients
>>> tab
>>> would be a good idea. I'm not a UX expert, there is probably a way to
do
>>> what you want nicely ...
>> Maybe Resource Server is a misleading name? Maybe it should be named a
>> Resource Manager or Resource Catalogue? What about having a Resources
>> tab under Client that lists the "Resource Servers" attached to the
>> client and the ability to add/remove Resource Servers for that client?
>> Its just a different way to navigate.
> Don't think Resource Server is a misleading name. It is a pretty well
> concept on OAuth2 world.
>
> Maybe I can give a shot to your suggestion and move all AuthZ UIs to a
> "Resource Server" tab. Or even have all those AuthZ UI tabs as separated
> tabs. Will send you screenshots with the result.
>
> [NOTE]
> I think I misunderstood your original question about the 1:1 mapping
> between RS and Clients. My answer was based on a conceptual view of those
> entities, where RS and Client may represent or not the same entity.
> From a implementation view, RS and Client have 1:1 mapping.
A Client can be associated with more than one Resource Server?
No, one-to-one. See
https://keycloak.gitbooks.io/authorization-services-guide/content/topics/....
Will put screenshots there, as we discussed.
>
>> Across the board, for all of Keycloak, we need to put some thought into
>> how to make things easier to configure with intuitive defaults, etc.
>> For example, there has been some talk of having ZERO config at the
>> adapter side except the realm URL and a client token. Apps would then
>> pull down all of their configuration from Keycloak.
> See, config is already minimal. Beside the keycloak-authz.json we
> discussed, you just need to change web.xml and
> jboss-deployment-structure.xml. The first is a necessary evil, but I can
> remove the latter.
Seems like if its all built into the same adapter, then there's a lot
less configuration steps
All this doesn't need to be done for first release. I'm just giving
feedback :)
God bless you
4:44 p.m.
New subject: Feedback
Regarding adapter config, I'm going to quickly rewrite the AuthZ Client API.
Currently, this API is based on ResteasyClient.
Will change it to be solely based on org.apache.httpcomponents:httpclient and keep even
more lightweight. That should be enough to let me change current adapters to support authz
config and keep config more simple.
----- 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: Wednesday, June 8, 2016 4:34:31 PM
Subject: Re: [keycloak-dev] Feedback
----- Original Message -----
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
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: Wednesday, June 8, 2016 4:29:42 PM
Subject: Re: Feedback
On 6/8/16 3:12 PM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: "Pedro Igor Silva" <psilva(a)redhat.com>,
"keycloak-dev"
>> <keycloak-dev(a)lists.jboss.org>
>> Sent: Wednesday, June 8, 2016 3:25:53 PM
>> Subject: Re: Feedback
>>
>>
>>
>> On 6/8/16 11:23 AM, Pedro Igor Silva wrote:
>>> Hi All,
>>>
>>> Asked Bill for some feedback about AuthZ docs [1] and would like to share
>>> with you.
>>>
>>> @Bill, my initial comments inline.
>>>
>>> [1] https://keycloak.gitbooks.io/authorization-services-guide/content/
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke(a)redhat.com>
>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com>
>>>> Sent: Wednesday, June 8, 2016 11:15:03 AM
>>>> Subject: Re: Feedback
>>>>
>>>> * Example is too complex. Needs to be broken down and explained for
>>>> each policy that was created.
>>> OK. By "broken down" you mean using sub-topics (pages) or just
sections
>>> on
>>> the same page ?
>>>
>>> The "Hello World" one should be fine because it is just a single
policy
>>> example. The "Securing a Servlet Application" may have more
details about
>>> each of those policies, will work on that. Or even just point to their
>>> respective documentation, as we also have doc for each policy type.
>>>
>>>> * Example should not use JSON import. It should walk through screen
>>>> shots to explain how to set up things.
>>> The idea behind using JSON import is that it provides an easy and fast
>>> way
>>> to users get started. After all, you just need to copy&paste
>>> configuration
>>> (or obtain from examples dir) and import to KC. IMO, that makes the
>>> tutorial more easy to follow with focus on the main concepts being
>>> explained.
>> JSON is great for running an example, but not great for documentation.
> OK. Changing ...
>
>>> I'm trying to keep documentation about UI on each topic, so you can see
>>> how
>>> to use admin console to create/configure things.
>>>
>>>> * Need more screenshots throughout doc
>>> Probably related with your previous feedback. I'm going to take some
more
>>> screenshots ....
>>>
>>>> * Is Resource Server->Client always a one-to-one thing?
>>> No, RS<->Client is not always a 1:1 mapping. Usually, they would be
>>> different entities, where the client is acting on behalf of the RO to
>>> access protected resources on a resource server. That is true for most
>>> API
>>> security use cases.
>>>
>>> However, an app may use both hats. For instance, monolithic JEE apps.
>>>
>>>> Maybe Authorization should move under clients tab?
>>> That is a good question. And my quick answer for that would be to keep it
>>> separated for now.
>>>
>>> I think changes like that may involve more discussions around UI design.
>>> For instance, today clients and resource servers are managed in the same
>>> space (Clients in left menu bar). As you know, clients (entities
>>> accessing
>>> a RS on behalf of an user) and RSs are different things and although they
>>> share a lot of things, I think we could have have them *visually*
>>> separated somehow.
>>>
>>> AuthZ includes more tabs and flows, so I don't think move under clients
>>> tab
>>> would be a good idea. I'm not a UX expert, there is probably a way to
do
>>> what you want nicely ...
>> Maybe Resource Server is a misleading name? Maybe it should be named a
>> Resource Manager or Resource Catalogue? What about having a Resources
>> tab under Client that lists the "Resource Servers" attached to the
>> client and the ability to add/remove Resource Servers for that client?
>> Its just a different way to navigate.
> Don't think Resource Server is a misleading name. It is a pretty well
> concept on OAuth2 world.
>
> Maybe I can give a shot to your suggestion and move all AuthZ UIs to a
> "Resource Server" tab. Or even have all those AuthZ UI tabs as separated
> tabs. Will send you screenshots with the result.
>
> [NOTE]
> I think I misunderstood your original question about the 1:1 mapping
> between RS and Clients. My answer was based on a conceptual view of those
> entities, where RS and Client may represent or not the same entity.
> From a implementation view, RS and Client have 1:1 mapping.
A Client can be associated with more than one Resource Server?
No, one-to-one. See
https://keycloak.gitbooks.io/authorization-services-guide/content/topics/....
Will put screenshots there, as we discussed.
>
>> Across the board, for all of Keycloak, we need to put some thought into
>> how to make things easier to configure with intuitive defaults, etc.
>> For example, there has been some talk of having ZERO config at the
>> adapter side except the realm URL and a client token. Apps would then
>> pull down all of their configuration from Keycloak.
> See, config is already minimal. Beside the keycloak-authz.json we
> discussed, you just need to change web.xml and
> jboss-deployment-structure.xml. The first is a necessary evil, but I can
> remove the latter.
Seems like if its all built into the same adapter, then there's a lot
less configuration steps
All this doesn't need to be done for first release. I'm just giving
feedback :)
God bless you
10:04 p.m.
New subject: Feedback
Bill,
Got the authz stuff working with the adapters. It was a puzzle but I think I have
something.
Here are the most important changes:
* Added an authorization step into AuthenticatedActionsHandler, so I could perform the
authorization checks there and decide whether the request can continue or not.
* Authorization checks are now in adapter-core and they are generic, so we can support the
different adapters.
* Added a single keycloak-authz-client dependency to adapter-core. It provides a
lightweight API for accessing authz services (see doc) and doesn't bring new
dependencies, but only those already in use by adapter-core.
* Added an AuthorizationContext type to keycloak-core. It holds the authorization data and
can be obtained from a KeycloakSecurityContext (it is marked as transient). Instances are
set into KeycloakSecurityContext during the authorization process, so the application can
use it to check for permissions. In the future, it should allow us to bring the policy
decision point more close to the policy enforcement point. I was already using this class,
just moved to keycloak-core.
* 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.
* Added a "policy-enforcer" configuration to the adapter config. With this
option you can provide the different options to configure a policy enforcer.
As expected, adapter configuration is even more simple now, with less steps to get things
done.
Do you have any consideration ? Would like to update the authz doc and getting started
tutorials to reflect the config changes to adapters.
----- 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: Wednesday, June 8, 2016 4:29:42 PM
Subject: Re: Feedback
On 6/8/16 3:12 PM, Pedro Igor Silva wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Pedro Igor Silva" <psilva(a)redhat.com>, "keycloak-dev"
<keycloak-dev(a)lists.jboss.org>
> Sent: Wednesday, June 8, 2016 3:25:53 PM
> Subject: Re: Feedback
>
>
>
> On 6/8/16 11:23 AM, Pedro Igor Silva wrote:
>> Hi All,
>>
>> Asked Bill for some feedback about AuthZ docs [1] and would like to share
>> with you.
>>
>> @Bill, my initial comments inline.
>>
>> [1] https://keycloak.gitbooks.io/authorization-services-guide/content/
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke(a)redhat.com>
>>> To: "Pedro Igor Silva" <psilva(a)redhat.com>
>>> Sent: Wednesday, June 8, 2016 11:15:03 AM
>>> Subject: Re: Feedback
>>>
>>> * Example is too complex. Needs to be broken down and explained for
>>> each policy that was created.
>> OK. By "broken down" you mean using sub-topics (pages) or just sections
on
>> the same page ?
>>
>> The "Hello World" one should be fine because it is just a single
policy
>> example. The "Securing a Servlet Application" may have more details
about
>> each of those policies, will work on that. Or even just point to their
>> respective documentation, as we also have doc for each policy type.
>>
>>> * Example should not use JSON import. It should walk through screen
>>> shots to explain how to set up things.
>> The idea behind using JSON import is that it provides an easy and fast way
>> to users get started. After all, you just need to copy&paste configuration
>> (or obtain from examples dir) and import to KC. IMO, that makes the
>> tutorial more easy to follow with focus on the main concepts being
>> explained.
> JSON is great for running an example, but not great for documentation.
OK. Changing ...
>> I'm trying to keep documentation about UI on each topic, so you can see how
>> to use admin console to create/configure things.
>>
>>> * Need more screenshots throughout doc
>> Probably related with your previous feedback. I'm going to take some more
>> screenshots ....
>>
>>> * Is Resource Server->Client always a one-to-one thing?
>> No, RS<->Client is not always a 1:1 mapping. Usually, they would be
>> different entities, where the client is acting on behalf of the RO to
>> access protected resources on a resource server. That is true for most API
>> security use cases.
>>
>> However, an app may use both hats. For instance, monolithic JEE apps.
>>
>>> Maybe Authorization should move under clients tab?
>> That is a good question. And my quick answer for that would be to keep it
>> separated for now.
>>
>> I think changes like that may involve more discussions around UI design.
>> For instance, today clients and resource servers are managed in the same
>> space (Clients in left menu bar). As you know, clients (entities accessing
>> a RS on behalf of an user) and RSs are different things and although they
>> share a lot of things, I think we could have have them *visually*
>> separated somehow.
>>
>> AuthZ includes more tabs and flows, so I don't think move under clients tab
>> would be a good idea. I'm not a UX expert, there is probably a way to do
>> what you want nicely ...
> Maybe Resource Server is a misleading name? Maybe it should be named a
> Resource Manager or Resource Catalogue? What about having a Resources
> tab under Client that lists the "Resource Servers" attached to the
> client and the ability to add/remove Resource Servers for that client?
> Its just a different way to navigate.
Don't think Resource Server is a misleading name. It is a pretty well concept on
OAuth2 world.
Maybe I can give a shot to your suggestion and move all AuthZ UIs to a "Resource
Server" tab. Or even have all those AuthZ UI tabs as separated tabs. Will send you
screenshots with the result.
[NOTE]
I think I misunderstood your original question about the 1:1 mapping between RS and
Clients. My answer was based on a conceptual view of those entities, where RS and Client
may represent or not the same entity.
From a implementation view, RS and Client have 1:1 mapping.
A Client can be associated with more than one Resource Server?
> Across the board, for all of Keycloak, we need to put some thought into
> how to make things easier to configure with intuitive defaults, etc.
> For example, there has been some talk of having ZERO config at the
> adapter side except the realm URL and a client token. Apps would then
> pull down all of their configuration from Keycloak.
See, config is already minimal. Beside the keycloak-authz.json we discussed, you just
need to change web.xml and jboss-deployment-structure.xml. The first is a necessary evil,
but I can remove the latter.
Seems like if its all built into the same adapter, then there's a lot
less configuration steps
All this doesn't need to be done for first release. I'm just giving
feedback :)
8:39 a.m.
New subject: 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? Or should
AccessTokenResponse optionally contain the
RPT? Or optionally a query param for Implicit Flow? Or have both? I
don't know.
9:59 a.m.
New subject: 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 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.
10:11 a.m.
New subject: 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? 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?
10:23 a.m.
New subject: 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: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.
10:43 a.m.
New subject: 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
10:55 a.m.
New subject: 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.
12:12 p.m.
New subject: Feedback
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 -----
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
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.
9:30 a.m.
New subject: 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?
- 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/...
----- 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
10:51 a.m.
New subject: Feedback
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
1:50 a.m.
New subject: 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(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 :)
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...
> - 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.
> - 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 :-)
> - 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?
Btv. just noticed that 2 links from javascript policy page
https://keycloak.gitbooks.io/authorization-services-guide/content/topics/...
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/...
>>
>>
>> ----- 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
>
11:08 a.m.
New subject: Feedback
----- Original Message -----
From: "Marek Posolda" <mposolda(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: "Bill Burke" <bburke(a)redhat.com>, "keycloak-dev"
<keycloak-dev(a)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(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 :)
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/...
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/...
>>>
>>>
>>> ----- 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
>>
3485
days inactive
3497
days old
17 comments
3 participants
participants (3)
-
Bill Burke -
Marek Posolda -
Pedro Igor Silva