[keycloak-dev] Feedback

[Pedro Igor Silva]

Bill,

Got the authz stuff working with the adapters. It was a puzzle but I think I have something.

Here are the most important changes:

* Added an authorization step into AuthenticatedActionsHandler, so I could perform the authorization checks there and decide whether the request can continue or not.
* Authorization checks are now in adapter-core and they are generic, so we can support the different adapters.
* Added a single keycloak-authz-client dependency to adapter-core. It provides a lightweight API for accessing authz services (see doc) and doesn't bring new dependencies, but only those already in use by adapter-core.
* Added an AuthorizationContext type to keycloak-core. It holds the authorization data and can be obtained from a KeycloakSecurityContext (it is marked as transient). Instances are set into KeycloakSecurityContext during the authorization  process, so the application can use it to check for permissions. In the future, it should allow us to bring the policy decision point more close to the policy enforcement point. I was already using this class, just moved to keycloak-core.
* I've discarded my own sub-types of AccessToken, they were redundant. The only difference between authz tokens and access tokens was a list of permissions. And the concept behind them is the same. I've added a "authorization" claim to AccessToken (null by default) from where permissions granted by the server can be obtained.
* Added a "policy-enforcer" configuration to the adapter config. With this option you can provide the different options to configure a policy enforcer.

As expected, adapter configuration is even more simple now, with less steps to get things done.

Do you have any consideration ? Would like to update the authz doc and getting started tutorials to reflect the config changes to adapters.

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

>
>> 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 :)