[keycloak-dev] Feedback

[Bill Burke]

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.

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

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

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

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