Re: [keycloak-dev] Feedback

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt;, "keycloak-dev" <keycloak-dev(a)lists.jboss.org&gt; > 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&gt; >>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>> 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.

> 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.