Nested group memberships and SSO

jwilson

We're rolling PDP out across many of our datasets to enable us to use embeded cards throughout our internal systems.  We may have just stumbled upon what is either a bug or a use case that wasn't properly expressed during development.  It appears that Domo isn't properly decomposing these group relationships and our SSO-authenticated users don't have the permissions to data they should.

 

We make considerable use of nested groups within our AD as it allows us to describe our hierarchical structure in a way that is maintainable.

 

Here's an example.

  - We have 40 stores (Store A, Store B, etc.)

  - The stores are managed in "regions" (Region 1, Region 2, etc.)

  - A regional manager may be in the "Region 1" group which itself may be a member of "Store A", "Store B", "Store C", etc.

 

Currently when this regional manager logs into Domo, he is not able to see data for Store A, B and C even though AD says he should.  Domo ONLY sees the Region 1 membership and no further.

 

 

Has anyone else run into this issue?  Were you able to work around it without abandoning your AD group architecture?

jwilson

I've had a couple people DM me so I've decided to put the instructions here for everyone.

 

We started by setting up SSO to Domo's documented standard.  Everything worked fine EXCEPT nested groups weren't decomposed.

 

To "fix" nested groups we modified the standard Relying Party Trust and initial set of Claim Rules as follows:

 

First, we added two new Claim Rules:

 

1 - UserDN Rule

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> add(store = "Active Directory", types = ("https://fs.storagepost.com/myclaims/UserDN"), query = ";distinguishedName;{0}", param = c.Value);

2 - MemberOfDN Rule

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
&& c2:[Type == "https://fs.storagepost.com/myclaims/UserDN"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/Group"), query = "(member:1.2.840.113556.1.4.1941:={1});distinguishedName;{0}", param = c1.Value, param = c2.Value);

 

Now our rules looked like this:

All Claim Rules

 

 The last thing we did was revise Domo's standard Claim Rule so it now looks like the attached.

 

Modified Domo Standard Claim Rule

 

Chronos

Is anyone able to help out with this request?

jwilson

We solved this ourselves.  It involves writing two custom claims rules and substituting one for the generic "Group" claim included in Domo's documentation.

 

If anyone would like more detail, please feel free to DM me.

jwilson

I've had a couple people DM me so I've decided to put the instructions here for everyone.

 

We started by setting up SSO to Domo's documented standard.  Everything worked fine EXCEPT nested groups weren't decomposed.

 

To "fix" nested groups we modified the standard Relying Party Trust and initial set of Claim Rules as follows:

 

First, we added two new Claim Rules:

 

1 - UserDN Rule

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> add(store = "Active Directory", types = ("https://fs.storagepost.com/myclaims/UserDN"), query = ";distinguishedName;{0}", param = c.Value);

2 - MemberOfDN Rule

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
&& c2:[Type == "https://fs.storagepost.com/myclaims/UserDN"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/Group"), query = "(member:1.2.840.113556.1.4.1941:={1});distinguishedName;{0}", param = c1.Value, param = c2.Value);

 

Now our rules looked like this:

All Claim Rules

 

 The last thing we did was revise Domo's standard Claim Rule so it now looks like the attached.

 

Modified Domo Standard Claim Rule