[keycloak-dev] Feedback

[Pedro Igor Silva]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: 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 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?

No, one-to-one. See https://keycloak.gitbooks.io/authorization-services-guide/content/topics/resource-server/create.html.

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

>