<div dir="ltr">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. <div><br></div><div>SCIM also <a href="https://datatracker.ietf.org/doc/html/rfc7643#section-4.1.2">made the decision</a> 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".</div><div><div><br></div><div>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 (<a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-group-claims">https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-group-claims</a>). There is often value decoupling the enterprise directory's view of group membership from the view for the specific app in my experience.</div></div><div><br></div><div>-Karl</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Mar 13, 2025 at 10:32 AM Dick Hardt <<a href="mailto:dick.hardt@gmail.com">dick.hardt@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>broke out nested groups discussion</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 12, 2025 at 10:53 PM Andrii Deinega <<a href="mailto:andrii.deinega@gmail.com" target="_blank">andrii.deinega@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Wed, Mar 12, 2025 at 2:25 PM Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 12, 2025 at 8:47 PM Andrii Deinega <<a href="mailto:andrii.deinega@gmail.com" target="_blank">andrii.deinega@gmail.com</a>> wrote:<br></div></div></div></blockquote></div></div></blockquote><div><snip><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br>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.<br></div></div></blockquote><div><br>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. <br></div></div></div></blockquote><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>To clarify your suggested, nesting groups would then only be allowed in the metadata command? Something like:<br><br><div><font face="monospace">"groups": [</font></div><div><font face="monospace"> {</font></div><div><font face="monospace"> "id": "983764",</font></div><div><font face="monospace"> "display": "staff",</font></div><div><font face="monospace"> "groups": [</font></div><div><font face="monospace"> {</font></div><div><font face="monospace"> "id": "983765",</font></div><div><font face="monospace"> "display": "engineering",</font></div><div><font face="monospace"> "groups": [</font></div><div><font face="monospace"> {</font></div><div><font face="monospace"> "id": "983766",</font></div><div><font face="monospace"> "display": "backend"</font></div><div><font face="monospace"> }</font></div><div><font face="monospace"> ]</font></div><div><font face="monospace"> }</font></div><div><font face="monospace"> ]</font></div><div><font face="monospace"> },</font></div><div><font face="monospace"> {</font></div><div><font face="monospace"> "id": "983767",</font></div><div><font face="monospace"> "display": "management",</font></div><div><font face="monospace"> "groups": [</font></div><div><font face="monospace"> {</font></div><div><font face="monospace"> "id": "983768",</font></div><div><font face="monospace"> "display": "executive"</font></div><div><font face="monospace"> }</font></div><div><font face="monospace"> ]</font></div><div><font face="monospace"> }</font></div><div><font face="monospace">]</font></div></div><div><br>And the value would be that an OP would then be able to send just the claim </div><div><br></div><div>"groups":"983766" // id for backend<br></div><div><br></div><div>in an id_token or an activate or maintain command, and the RP would know the user is the backend, engineering, and staff groups? </div><div><br></div><div></div>An interesting idea. <br><br>My pushback would be if the added complexity required by all RPs to understand and model nested groups is worth the benefits.<br><br>My philosophy for OP Commands (and standards in general) is minimize the required functionality for interop. </div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br><br>/Dick</div></div></div></div></div>
</blockquote></div>