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

[Pedro Igor Silva]

On Mon, Mar 13, 2017 at 2:10 PM, Bill Burke <bburke at redhat.com> wrote:

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

The confusion is because we have this JIRA
https://issues.jboss.org/browse/KEYCLOAK-3135. Currently, we don't have a
nice REST API for policy management. That explains why we lack docs as
well. You can use KC Admin Client (that is what we use in tests) but that
will change once we introduce a specific API for this purpose.


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

I don't think I've overloaded concepts. The concept of a policy is much
more broader than with a permission. A policy can be seen as a condition
that must be satisfied in order to grant/deny access to something (resource
or scope). You can reuse policies across different permissions (you
probably want that instead of replicating the same condition on similar
policies), policies can be combined to form more complex and fine-grained
conditions (see aggregated policies), etc.

On the other hand, permissions are what you actually use to say: "OK, here
is the thing I want to protect with these policies". Initially, we didn't
have the "permission" concept at all and that was blocking us to be more
flexible and support more functionalities.

What magic you are talking about ?


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

There are a few things more than just "are you allowed to do this" :) You
may get to a decision in different/configured ways. Glad that you are now
looking into this.

What I meant is that we kind of support a parent/child relationship between
resources with typed resources [1]. Just thinking loud about what we may
(or not) need to use authz internally.

[1]
https://keycloak.gitbooks.io/authorization-services-guide/topics/permission/typed-resource-permission.html


>
>
> Bill
>