[keycloak-dev] fine-grain admin permissions with Authz
bburke at redhat.com
Mon Mar 13 17:38:33 EDT 2017
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
>>> 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
>> 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
>>> 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
> 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 . Just
>> thinking loud about what we may (or not) need to use authz
> 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
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?
More information about the keycloak-dev