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

[Pedro Igor Silva]

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.


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

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 ?

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


>
> Bill
>