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

[Bill Burke]

On 3/13/17 1:27 PM, Pedro Igor Silva wrote:
> On Mon, Mar 13, 2017 at 2:10 PM, Bill Burke <bburke at redhat.com 
> <mailto: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
>>     <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.
>
>
> 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.

I'm sorry.  I sounded too critical and I didn't mean to be or sound like 
I was attacking you.  I really like what you are doing and am excited 
about it...but...You do overload concepts because the admin console has 
the concept of a Permission and there's no Permission object in the REST 
API, the model api, or the data model. Permission looked like a join 
table between Resource and Policy or Resource, Scope, and Policy.  From 
your docs and admin console it looks like you have 4 concepts:

* The thing (Resource)
* The action (scope)
* The condition (policy)
* The permission (join of resource, scope, and policy).

>
> 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.
>
Yeah, Keycloak didn't have the concept of "Resource", "Scope", or 
"Policy".   Role was really just a way to catagorize users.  Is that 
what you mean?

> 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 is the more?  I understand you can get to a decision in different 
ways.  That's what is really cool about your stuff...but what exactly 
are you "deciding" on?  Again I thought we were deciding what actions 
can somebody perform on a resource.

Some other related questions:
* What is a "resource permission" supposed to be?  Is it a "catch all" 
for that resource?
* What if you have multiple "scoped permissions" defined for the same 
resource and scope.  Do they all have to be true?  Or just one?


> 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

That looks interesting, but there's currently no way to say: For this 
resource type and these scopes, apply these policies.  The "scope" part 
is missing.

Bill