On Mon, Mar 13, 2017 at 7:03 PM, Bill Burke <bburke(a)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