[keycloak-dev] fine-grain admin permissions with Authz

[Bill Burke]

On 3/13/17 11:49 AM, Pedro Igor Silva wrote:
>
> On Mon, Mar 13, 2017 at 12:15 PM, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     On 3/13/17 9:43 AM, Pedro Igor Silva wrote:
>>
>>     Are you already implementing things ? Do you want me to look at
>>     these changes or work together with you on them ?
>>
>>     (As you may have noticed, there is an API that we use internally
>>     to actually evaluate policies given a set of permissions.)
>     Haven't implemented anything just researching how it could be
>     done.  The biggest issue right now that I'm having is that I don't
>     understand how to do things programatically yet (i.e. set up
>     resources, set up scopes, set up permissions, set up policies).  I
>     don't understand how the UI translates to the JPA entity model and
>     there seems to be a lot of set up data hidden by generic Map
>     objects.  Its also really confusing how the admin REST interface
>     translates from the UI to the model.    Its also really bizarre to
>     me that the things represented in the Admin Console UI are not
>     represented in the data model.  i.e. I have no idea how a
>     "Scoped-Permission" in the admin console maps to a JSON
>     representation, the REST API, nor how that JSON representation is
>     mapped to the model.
>
>
> The usage of Map objects is similar to what we have with identity 
> brokering. We need to be flexible in order to support different types 
> of policies without requiring changes to model.
>

> Regarding representation, both permission and policy are represented 
> as policies. What differs a permission from a policy is the type. 
> Policies defined as "scope" or "resource" (as you have in UI) are the 
> ones you can use to actually create permissions to resources and scopes.
>
This is the really confusing part.  There is no documentation on how to 
set up a Scoped or Resource permission through the REST API.  The 
AuthzClient only allows you to create resources AFAICT.  I'm currently 
tracing through admin-console permission UI to find which REST endpoint 
to use, and how that REST endpoint converts JSON into actual API calls.

> Everything you need is available from an AuthorizationProvider 
> instance, which can be obtained as follows:
>
> KeycloakSession.getProvider(AuthorizationProvider.class);
>
> From an instance of that class you can access methods to evaluate 
> permissions or obtain references to the different storages we use to 
> actually manage resources, policies, scopes and resource servers. I 
> can include the AuthZ API as a topic to our meeting about authz 
> services next week.
>
I don't have everything I need as you overload concepts (permission and 
policy) and it doesn't make sense yet the magic that must be done to 
store these definitions.

> Regarding scope-based permissions and the use cases you pointed out, I 
> think we may have to change how we are handling typed resources. 
> Today, we know a resource is a general/typed resource because the 
> owner of the resource is the resource server itself, and resource 
> instances are usually owned by an user, someone different than the 
> resource server. Need to take a look on this one and see how it impact 
> the use cases you pointed out ...
I have no idea what you're talking about here.  Am I missing something 
fundamental here?  From the docs, examples, and the admin console UI, I 
thought Authz was about defining rules (policies) to determine if 
somebody is allowed to perform a specific action (scope) on a certain 
thing (resource).

Bill