6:19 a.m.
Bill, I was thinking about this and would like your thoughts about an idea.
In order to enforce policies to a resource, you don't necessarily need to
create a protected resource in AuthZ Services. As you already noticed, when
sending an authorization request (or using the AuthZ API internally) you
can send the resource(s) and scope(s) you want to access.
What if instead of creating resources for each thing you want to protect
(groups, roles, clients, etc) we just associate them with a specific
protected resource in AuthZ Service ? For instance, one of the use cases
you proposed is:
Admin can only apply certain roles to a user
We would have a protected resource called "Special Role" which is
associated with a permission/policies that must be satisfied in order to
allow an administrator to grant a specific role to an user. That way,
before granting a role, you would check the resource associated with the
role and ask the policy evaluation engine for permissions.
I think that would work if "to a user" means any user, otherwise we would
need to pass additional contextual data along with an authorization
request, like we previously discussed.
What do you think ?
On Wed, Mar 22, 2017 at 8:11 PM, Pedro Igor Silva <psilva(a)redhat.com> wrote:
I'll be busy this week and probably next week preparing a PR with
Elytron
adapters. Just sent an email about it.
If you can wait until there ...
Regards.
Pedro Igor
On Wed, Mar 22, 2017 at 7:52 PM, Bill Burke <bburke(a)redhat.com> wrote:
> I need it to move forward. You or me. I don't care.
>
> On 3/22/17 5:45 PM, Pedro Igor Silva wrote:
>
> Btw, are you already looking this or do you want me to write it down ?
>
> On Wed, Mar 22, 2017 at 6:08 PM, Pedro Igor Silva <psilva(a)redhat.com>
> wrote:
>
>> I see. That makes sense. It would save a lot of work and can also be
>> useful for people looking to hook their own resources without necessarily
>> creating them.
>>
>> Regards.
>> Pedro Igor
>>
>> On Wed, Mar 22, 2017 at 5:04 PM, Bill Burke <bburke(a)redhat.com> wrote:
>>
>>> I want to use AuthZ service to implement fine-grain admin console
>>> permissions. To do this, I foresee that I'll have to define resources
>>> that correspond one to one to objects in the Keycloak domain model.
>>> Specifically roles, groups, and clients. There are a few problems with
>>> this approach:
>>>
>>> * Some deployments of keycloak have tens of thousands of roles and
>>> groups or hundreds of clients
>>> * Synchronizing an AuthZ resource that represents a role, group, etc.
>>> must be done. i.e. when role/group/client is removed or renamed.
>>> * I'd like for policies to be able to have the real object that the
>>> resource represents when evaluating policies
>>>
>>> I want to suggest something similar that we've done with User Storage
>>> SPI in that links to AuthZ resources are a "smart" id.
>>>
>>> "f:" + providerId + ":" + resource id
>>>
>>> When evaluating policies the engine would navigate to a provider that
>>> could load an instance of the Resource interface. This way I could
>>> represent a role or group as an AuthZ resource without creating a
>>> resource in the Authz datamodel. Am I making sense?
>>>
>>> Bill
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
>