[keycloak-dev] fine-grain admin permissions with Authz
bburke at redhat.com
Mon Mar 13 15:20:02 EDT 2017
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 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
>> Everything you need is available from an AuthorizationProvider
>> instance, which can be obtained as follows:
>> 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 . Just thinking loud about
> what we may (or not) need to use authz internally.
That looks interesting, but there's currently no way to say: For this
resource type and these scopes, apply these policies. The "scope" part
More information about the keycloak-dev