[keycloak-dev] Feedback

[Pedro Igor Silva]

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

> 
> >> * 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 ?

> 
>