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 -----
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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev