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

[Pedro Igor Silva]

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

>
>
> 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> 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> 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.
>>
>>
>> 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-guid
>> e/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.
>

By "local-java-API" you mean use that AuthorizationProvider I mentioned
earlier ? That is what I meant by using the AuthZ API (the Java API we use
internally in authz services).

Regarding the admin console, the only thing to keep in mind is how much
permissions you are going to get from the server. We also support sending
along a entitlement request the resource/scopes you want to access. That
can help to perform incremental authorization instead of obtaining
everything once from the server.


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

It makes sense to provide separated UIs. Although we can also try to re-use
authz UIs and see how it looks like. Not sure if usability will be so bad.


>
>
> Bill
>
>