I'm sure there are benefits of a group belonging to groups, but I think it's outweighed by the complexity involved.

On 20 October 2015 at 13:48, Marek Posolda <mposolda@redhat.com> wrote:
That's similar to how it worked for GateIn portal . There was only
parent-child notion and each group could be identified easily by path
consisting of it's simple name and parent hierarchy. For example root
group "platform" had path "/platform" . The subgroup "finance" of root
group "platform" had path "/platform/finance" etc.

All the roles were always assigned to user per group, so there was
notion like: User "john" is member of role "admin" in group
"/platform/finance" etc. Visualization was quite easy - some screenshots
are here:
https://docs.jboss.org/author/display/GTNPORTAL39/Manage+Users+and+Groups .

I think this model was sufficient (at least for portal purposes). Can't
any customer wanted the structure with group being child of multiple
parent groups.

Marek


On 19/10/15 16:40, Bill Burke wrote:
> I was wondering if it would be ok to only have parent/child, tree
> structure relationship between groups.  Meaning, a group can't belong to
> multiple groups.
>
> I was just thinking about modeling a large company with groups.  How
> would you visualize the group structure within the admin console?  A
> hierarchical-only group structure would allow you to define a group with
> a simple non-unique names.  i.e. "admins", "customers".

_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev