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

[Pedro Igor Silva]

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

>
>
> On 3/13/17 5:54 PM, Pedro Igor Silva wrote:
>
>
> 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).
>
> Yes, I think that's the one.
>
> 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.
>
> Yeah, I saw that.  Not sure what the best way would be.  Just think of the
> admin console main screen.  If you can only manage users of a specific
> group there's a bunch of menu items that wouldn't show up.
>

For the main screen, I think we can have a single resource with scopes
representing each link on the menu. Then we can ask for "give me
permissions for Main Page" and have only the set of permissions required to
load the main page.

Another thing I was holding to implement is a way to configure which
resources can be obtained as a result of a general entitlement request
(without any specific resource and scope). So you can have more control
over the initial load of permissions and use incremental authorization for
the rest on a per resource basis.


>
>
>
>
>>
>> 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.
>
>
> Really depends on the realm and what approach we want to take.  Do we want
> one place where all permissions are decided?  Then something like a tree
> view would be need to navigate all the clients, roles, groups and other
> managable resources a realm might have.  One of our customers has hundreds
> of roles and thousands of groups and hundreds of thousands of users.
> Another approach is have an Authz tab on each thing we want to have fine
> grain permissions on.  I.e. the role page would have a "Management
> permissions" tab.
>

Yeah, considering that use case a tree would also suffer from
usability/performance issues. On the other hand, a specific tab on each
resource looks more "bullet proof" but bring usability issues.

I think AuthZ UI can handle this as well depending on how we decide to do
things. For instance, suppose we are creating a role. At that point we also
create a "Role A Permission" with a default policy (probably granting
things to superuser only). Later, if you want to change the
permission/policies for this role you can go to AuthZ UIs and perform a
partial search on the permission list for "Role A", which will bring you
the "Role A Permission".

Something to try before implementing more things, I think ...


>
> Bill
>