Portal for ArcGIS SAML Group Membership - #BUG-000122852

6756
26
06-10-2020 05:56 AM
MathiasGieser
New Contributor III

BUG-000122852: Portal for ArcGIS does not refresh the membership fo.. 

We discovered this bug last year during our 10.7 install and configuration.  This is a key feature we were hoping to leverage and have since been unable to do so and required a third party integration be developed to sync our portal with employee directory.

It is still in the new status.  Can someone from ESRI shed some light on the path of this bug being fixed? Has anyone else experienced this bug?  Any work arounds?

Mathias

0 Kudos
26 Replies
JeffSmith
Esri Contributor

No, unfortunately the issue related to having multiple Portal groups linked to a single SAML enterprise group is not fixed in 10.9.  We are hoping to have it addressed in 10.9.1.

0 Kudos
by Anonymous User
Not applicable

@JeffSmith wrote:

Currently it is possible to enable SAML enterprise groups when you configure SAML and also have an Active Directory or LDAP group store defined in portaladmin.  When this happens they conflict with each other and you see weird results.  We are working on an enhancement to only allow one or the other.


It would be good if this was mentioned in the documentation somewhere! That and some clearer guidance on how Portal groups can be setup when using SAML. From what you mention if SAML is enabled are only SAML groups supported? Or can we have inbuilt Portal groups which hold SAML users (who are all in one SAML enterprise group) i.e. leave SAML to deal with which users can access Portal, and inbuild Portal groups for managing who can access items etc. within Portal

0 Kudos
JeffSmith
Esri Contributor

@Anonymous User  Thanks for the suggestion.  I will review the documentation and try to add a warning concerning the potential impact of having SAML enterprise groups enabled along with an Active Directory or LDAP group store defined in portaladmin.  Regarding your question on groups, yes, when SAML enterprise groups are enabled, you can still create Portal groups whose memberships are managed by the group owner.  This option is never disabled.

When SAML enterprise groups are enabled, you still go through the same workflow when creating new groups.  You are just provided an additional option for how members are managed: managed by the group owner or managed by SAML logins.  If the membership is managed by SAML, only enterprise users can be members and they are only added to the group after they login.  Built-in portal members cannot be added to these groups.  If the membership is managed by the group owner, there are no restrictions and both enterprise or built-in portal members can be added or removed as desired.

0 Kudos
by Anonymous User
Not applicable

Thanks @JeffSmith. We've moved to SAML but the overhead of creating groups in our organization and not being able to link multiple Portal groups to a SAML group meant using inbuilt groups was far more manageable. We did try both SAML and AD config and that's when I came across this thread 🙂 as things weren't lining up.

0 Kudos
WilliamShoop
New Contributor III

Good morning all,

Not sure if this applies to everyone in this thread or that ESRI is aware but in our enterprise, we saw that only certain users were unable to be added to Portal groups via SAML. We configured our SAML-group based membership with Azure AD and when I tested with my account, I was assigned to the appropriate Portal groups based on my AD groups, but later found out not all users were being assigned. Upon investigating I found the article at the bottom of this message describing SAML responses that causes this behavior. If a user is a member of a lot of AD groups, the SAML response with provide a link instead of a listing of the user's AD groups. The link does not work with the GIS Portal, because it is specifically looking for the listing of AD groups to link it to the Portal groups. To fix this we are working with our server team to configure Azure AD to only send over the AD groups related to our Portal, so the list is not cumbersome. Using the SAML Message Decoder Chrome extension you can see the difference in the response AD list vs link:

Working Account

<Attribute Name=http://schemas.microsoft.com/ws/2008/06/identity/claims/groups>

<All groups listed…..>

 

Defective Account

<Attribute Name=http://schemas.microsoft.com/claims/groups.link>

<AttributeValue>https://graph.windows.net/3a86ebff-1254-450e-bd5e-161fedab6b9a/users/275ed1e6-0b3b-4662-9dae-5b60f14...>

 

https://docs.microsoft.com/en-us/azure/active-directory/develop/reference-saml-tokens 

 

I hope this helps,

Bill

JenaF
by
New Contributor II

Hey all - 

Chiming in here with what worked for us. We're still on 10.8.1. I got our organization AD IT specialist involved for the Azure AD admin center stuff.

1) In Azure Active Directory admin center, we added a group claim to the Portal application and configured it to use "Groups assigned to the application" and the Source attribute of "sAMAccount Name". I think returning only the groups assigned to the application resolves the issue of a user being a member of too many groups (as not all their groups will be returned, only the ones associated with Portal in Azure AD). This gets done once per application (i.e., per Portal - if you have Dev, Test, and Prod you would set this up three times, but once it's set it's set for good).

JenaF_0-1685131421935.png

2) Still in Azure AD admin center, we also associated the groups of interest with the application (the Portal of interest; ours is named Portal for ArcGIS TEST). As new Portal groups are set up to track AD groups, those AD groups will need to be added here, particularly if you have the claim set to only return 'Groups assigned to the application'.

JenaF_1-1685132010720.png

3) In ArcGIS Portal, I configured a group per the normal instructions for linking SAML groups. In our case, the Enterprise group name was just the group name, no domain prefix. I think this is because the Source attribute set in Azure AD admin center is just the group name. There is a dropdown option for using a prefix but we didn't use that one.

4) As mentioned by WilliamShoop, the SAML decoder extension (https://chrome.google.com/webstore/detail/saml-message-decoder/mpabchoaimgbdbbjjieoaeiibojelbhm) was very useful for checking the group attribute format in the SAML response. Install it, log into Portal, then check the SAML response available in the extension. 

Good luck,

Jena

 

 

0 Kudos
frobertsmaf
New Contributor III

@JenaF I haven't seen many people use this function of ArcGIS Enterprise.  Would you be willing to chat with me about how you guys set it up?  Sorry to but you but you seem to be the latest one to post on this topic.  If you have other refrence materials you used if you can provide them that would be great!

0 Kudos