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?
Based on the information provided in the bug, this issue cannot be reproduced. I have tested this on 10.7 and later releases and in all cases the group membership is refreshed correctly each time the enterprise user logs in. Access to content within those groups is updated as well. If a user is removed from an enterprise group and the SAML assertion at the next login reflects this, the group membership within Portal gets updated and the user is not able to access content shared with the linked group.
Thank you for taking the time to respond to my inquiry. Could the underlying operating system version and/or ADFS version be the difference in reproducing and not reproducing the error?
Using SAML Tracer in Chrome I am able to see the SAML responses and claims. The XML being returned for the Group claim looks like the following. Do you see the same?
Also, the group name values are blurred but are like the following "myDomain\the_group_name". Is this the valid format Portal is looking for? I have tried configuring Portal groups with and without the domain name value.
Yes, the SAML response looks correct and matches the response I see when using ADFS. The format of the group name that Portal expects depends on what you type in when you link the Portal group to the enterprise group. When using SAML-based enterprise groups, there is not a way to search or query for valid groups. The format and name of the enterprise group must be known beforehand and the user linking the Portal group just types it in. During a login, Portal compares that with the attribute values that are passed in through the SAML assertion (case-insensitive) and adjusts membership accordingly.
Keep in mind for SAML-based groups, there is not a way to refresh the membership through portaladmin. There is also not a regular 24-hour full refresh. The only refresh occurs when a user logs in.
We just discovered the same issue on ArcGIS Enterprise 10.8 !
When configuring a group viewable and joinable by only "Members of an Enterprise Group", users can't see them even when they are in the group.
It used to work ! The funny thing is that they can see old groups created with older version of Portal for ArcGIS that are configured the exact same way !!!
I decoded the reply from SAML when logging in:
And of course when trying to access webmap from that group, I get 403 error.
This is a big issue for us !!
OK, so I run additional tests on our UAT environment on 10.8 and it's working fine... but not in production with the very same SAML configuration on Portal.
The only difference I could think of about those 2 environments is that the production was upgraded from 10.7.1 while the UAT while in the meantime reconfigured from scratch...
On production, I removed SAML configuration and configured it again just like on UAT environment: same results, still not working
Wow! A wide variety of issues with this it seems. I had wondered if an upgrade to 10.8 would fix the issue, but I guess not.
I understand the complexities of integrating with a third party system like this and that it is not easy to build something and/or troubleshoot all cases. I can appreciate the effort and product planning put into this feature. However, I really wish ESRI would take a better approach to this and assist further and help fix this for us and presumably others.
Hi. I understand your frustration with this. There are many factors involved in some of these issues and while we try to perform testing in different configurations and scenarios, there are some that definitely get missed. I searched through our bug fixes for 10.8.1 and found one related to SAML group membership that you might be encountering.
BUG-000121049 - If an ArcGIS group links to a group in the SAML Identity Provider (IDP) is owned by a SAML user who is not listed as a member of the group in the SAML assertion response, the group membership of the user fails to update.
Since yours was working previously though and started failing after the upgrade, this may not apply to you. Due to the complexity in this issue and since you have 2 environments that behave differently, I would recommend contacting our Support team.
After reviewing BUG-000121049 and looking at the work around I found I was able to get it to work. Key elements being the group is owned by a non-SAML user (i used our primary administrator account) and the group name registered with Portal to be domain + "\" + group_name and not just group name.
Thanks for your reply Jeff Smith.
I am still investigating and I found out why it was working on one deployment and not the other: it was because I tested with a newly created account !
I deleted an account on production as it was only a 'viewer' and did not have any item, asked him to login again, and after initial login it worked ! User could access the group he could not see before because his account had been created again in Portal.
It means that group membership is computed at account creation but not computed for new groups. Does that help to identify the possible issue ?
BTW, I don't think it is BUG-000121049 as I am member of that of the group in the SAML response and creator of the group.