[keycloak-dev] Feedback

[Bill Burke]

On 6/8/16 3:12 PM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>, "keycloak-dev" <keycloak-dev at 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 at redhat.com>
>>>> To: "Pedro Igor Silva" <psilva at 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 :)