[keycloak-dev] fine-grain admin permissions with Authz
bburke at redhat.com
Mon Mar 13 13:10:07 EDT 2017
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.
> 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.
> 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
More information about the keycloak-dev