Yeah, it should be possible. Once Bill finishes his group stuff we can support that.
Right now, the Authz Server we're working on does not provide group-based policies,
which is a requirement to get your use case addressed.
But once groups are there, you can easily define a policy that let's you associate a
set of resources to a group and enforce authorization. We can even provide options to this
type of policy like:
- An option to enable/disable roles inheritance. In case you don't want to inherit
roles when checking for permissions.
- An option do enable/disable group hierarchy checks. In case you want to match only a
specific group.
I'll keep your scenario in mind and test with the Authz Server once we have groups
in.
Thanks.
----- Original Message -----
From: "Jorge Solórzano" <jorsol(a)gmail.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: "Bill Burke" <bburke(a)redhat.com>, keycloak-dev(a)lists.jboss.org
Sent: Wednesday, November 4, 2015 11:56:36 AM
Subject: Re: [keycloak-dev] roles vs. groups
Well, based on what you said on policies looks fine to me...
Give a look to the following scenario and if it can be acomplish with KC.
The organization has many subdivisions like this:
Org
|------Subsidiary 1
| |------Branch office 1.1
| | |------Office 1.1.1
| | |------Office 1.1.2
| |------Branch office 1.2
| |------Office 1.2.1
|------Subsidiary 2
| |------Branch office 2.1
| |------Office 2.2.1
| |------Office 2.2.2
...
Can I define authorization in a way that Office 2.2.2 can only touch
the resources specific to it, Branch office 1.1 can see the resources
of Office 1.1.2 and Office 1.1.1, Subsidiary 1 can see all in Branch
office 1.1 and 1.2... and so on...
Jorge Solórzano
On Wed, Nov 4, 2015 at 6:46 AM, Pedro Igor Silva <psilva(a)redhat.com> wrote:
>
> Let's supose, you have a group called "GroupA", that group have roles
> "Create invoice" this has 13 permisions, "Remove invoice" this
has 5
> permisions, "Update invoice" this has 19 permisions...
>
> I asign 25 users to Group A, but 2 users, should not have 3 permisions
> that are different in both users, should I need to create "GroupB" and
> "GroupC" with the exact permissions, just to handle this 3 permisions
> exclusions?
>
> It probably can be a little overkill, but IHMO is more flexible than
> an all or nothing approach.
>
I see your point. However, IMO, when you start to use negatives you may end up with
something more complicate and hard to follow.
What I meant by positive logic is not an all or nothing approach, but use positives
permissions and play with them to match your requirements.
For instance, we are developing some additional authorization features to Keycloak. There
you can define a set of policies that rule access to your resources based on different
type of access control mechanisms: rbac, contextual/risk-based, abac, user-based, etc.
Policies can be applied to a resource type, resource instance, a specific scope (eg.:
create, remove, delete, etc) or a combination of them. Policies are also independent of
each other and can be reused and combined in different ways to actually define and enforce
authorization for a given resource/scope.
Considering you scenario, you would have something like that:
- Only Group A Policy (defines that all members of Group A can *do something*)
- Resource X Policy (here we are telling what Group A can do. In this case, access
Resource X and any of its scopes)
- Applies Only Group A Policy
You can also have something like:
- Only Group A Policy (defines that all members of Group A can *do something*)
- Create Invoice Policy (here we're telling that Group A can access a specific
scope.)
- Applies Only Group A Policy
Now, if you want specific policies for some of your users, you can do something like:
- Exceptional Y Policy (which can define a specific user, role, group, any contextual
information like current time or authentication method)
- Create Invoice Policy
- Applies Only Group A Policy
- Applies Exceptional Y Policy
That will provide flexible policies, make them more meaningful and easy to
follow/understand. We are considering protect resources as important assets within an
organization, which should be ruled by a set of policies that must be applied before
accessing them.
I would appreciate if you could provide some more info about your use case. Right now
I'm writing some examples and would be nice to check how your requirements can be
addressed (or not :)) with what we did so far.
Thanks.
Pedro Igor