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

[Bill Burke]

On 3/13/17 4:34 PM, Pedro Igor Silva wrote:
> On Mon, Mar 13, 2017 at 4:20 PM, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     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
>>     <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?
>
>
> Don't worry, I know what you mean. You usually have a point when you 
> criticize something ......
>
> From the bottom up. I did not mean role and KC role mapping. By 
> "initially", I meant when I started AuthZ Services ....
>
> Regarding your point, that is exactly what we want to fix/provide with 
> that JIRA for "Remote Policy Management". Not only provide a REST API 
> on top of what we have, but make easier to manage policies for a 
> resource server. We definitely going to have a Permission object in 
> the REST API. Regarding the model and data model, we can discuss that 
> in a separated thread. This is an implementation detail that we can 
> easily solve.
>
>
>
>>     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.
>
>
> By more, I mean that a decision really depends on how you define your 
> policies. Where that "typed resource" thing I mentioned is one way to 
> define common permissions to a "parent" resource and have them also 
> applied to resource instances sharing the same type. There is also the 
> possibility to override permissions defined on a typed resource for a 
> given resource instance, the possibility to specify more fine-grained 
> policies to scopes associated with a resource even if that resource 
> has a permission (resource-based permission) associated with it, etc.
>
> But in a nutshell, yes we are basically determining which 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?
>
>
> Yes. A resource permission should be used when you want to define 
> policies for a given resource. In this case, if you get a PERMIT 
> you'll have access to all scopes associated with the resource as well.
>
>     * What if you have multiple "scoped permissions" defined for the
>     same resource and scope.  Do they all have to be true?  Or just one?
>
>
> For scope-based permissions, what our evaluation engine does is look 
> for PERMITs. So, if you have asked for all permissions an user has 
> (e.g.: using entitlement api) you'll get the scopes whose permissions 
> evaluated to a PERMIT.

So, if you have a set of permissions (scoped-base and resource base) it 
is a logical OR on all these permissions when evaluating.


>
>
>
>>     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
>>     <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.
>
>
> Right now, this is achieved by checking the scopes associated with the 
> resource that we consider to be the parent. Like I mentioned, we 
> assume that the parent/typed resource is the one whose owner is the 
> resource server itself.
>
> I have a question about what you are planning to do. Are you planning 
> to put our policy enforcer on top of Keycloak Admin API or are you 
> going to use the AuthZ API internally to enforce those decisions ?
>
Not sure what you mean by that question but I'll try and answer.... I 
want to integrate your stuff with Keycloak Admin REST API *and* the 
admin console.  REST API first though:  Want to use the local-java-API 
equivalent to the REST entitlement request.  See the example I described 
in the original post.  It seems like Authz can handle this.  For admin 
console UI, I was going to make a general entitlement request to obtain 
all permissions for a particular admin, then render the UI 
appropriately.  i.e. if the admin can't update the realm, doesn't see 
those screens.

Go to the original post on this email thread to see how I explained user 
role mappings and what things we want to offer there.

> From a UI perspective, are you planning to re-use the UIs we already 
> have in that "Authorization" tab or provide a specific set of UIs for 
> defining permissions to KC resources ?
My initial thought is that the Authz UI would not be re-used.  I think 
we need something more user friendly to navigate between all the 
resources we are going to have.  What do you think?

Bill