[Openid-specs-ab] nested groups (was: Review of OpenID Provider Commands (draft 00))

[Karl McGuinness]

Existing deployments of enterprise IdPs like ADFS, Entra ID, and Okta don't
support nested groups in SAML assertion or ID Tokens.  Using a simple
multi-value string type for group memberships increased interoperability
across deployments and technology frameworks that just support simple
key-value property dictionaries for a user's profile.

SCIM also made the decision
<https://datatracker.ietf.org/doc/html/rfc7643#section-4.1.2> to return a
flat list of memberships of the user attribute "groups"  stating "A list of
groups to which the user belongs, either through direct membership, through
nested groups, or dynamically calculated".

IdPs often provide rich functionality to filter, map, & reduce a a user's
group membership graph to a flat list of groups that are specific to the
relying party relationship (
https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-group-claims).
There is often value decoupling the enterprise directory's view of group
membership from the view for the specific app in my experience.

-Karl

On Thu, Mar 13, 2025 at 10:32 AM Dick Hardt <dick.hardt at gmail.com> wrote:

> broke out nested groups discussion
>
> On Wed, Mar 12, 2025 at 10:53 PM Andrii Deinega <andrii.deinega at gmail.com>
> wrote:
>
>> On Wed, Mar 12, 2025 at 2:25 PM Dick Hardt <dick.hardt at gmail.com> wrote:
>>
>>> On Wed, Mar 12, 2025 at 8:47 PM Andrii Deinega <andrii.deinega at gmail.com>
>>> wrote:
>>>
>> <snip>
>
>>
>>>> 3. I suggested enabling nested groups in section "6.1 Metadata
>>>> Command". Are there particular reasons for having and allowing only a plain
>>>> structure? That shouldn't be a big issue to remove this limitation in the
>>>> way I see it. Nested groups offer convenience and simplify their and
>>>> permission management.
>>>>
>>>
>>> Would you elaborate on how this would work? What would it mean if a
>>> group was in a group for a user? While groups can be made up of groups when
>>> defining a group, the account either belongs to a group or not.
>>>
>>
>> First of all, RPs can make use of the structure of groups (how they are
>> nested in each other) alone, I'd even say that in some cases, it's very
>> desirable to have this piece of information. Secondly, you don't need to
>> indicate in OP Commands such as "activate" that user1 is a member of
>> group1.1 when this group is included in group1.
>>
>
> To clarify your suggested, nesting groups would then only be allowed in
> the metadata command? Something like:
>
> "groups": [
>     {
>         "id": "983764",
>         "display": "staff",
>         "groups": [
>             {
>                 "id": "983765",
>                 "display": "engineering",
>                 "groups": [
>                     {
>                         "id": "983766",
>                         "display": "backend"
>                     }
>                 ]
>             }
>         ]
>     },
>     {
>         "id": "983767",
>         "display": "management",
>         "groups": [
>             {
>                 "id": "983768",
>                 "display": "executive"
>             }
>         ]
>     }
> ]
>
> And the value would be that an OP would then be able to send just the
> claim
>
> "groups":"983766" // id for backend
>
> in an id_token or an activate or maintain command, and the RP would know
> the user is the backend, engineering, and staff groups?
>
> An interesting idea.
>
> My pushback would be if the added complexity required by all RPs to
> understand and model nested groups is worth the benefits.
>
> My philosophy for OP Commands (and standards in general) is minimize the
> required functionality for interop.
>
> The RP can choose which commands it wants to implement, but if it wants to
> use groups, it could not just support a flat list of groups, it would need
> to support nested groups in your proposal.
>
> /Dick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250313/b70ae85b/attachment.htm>