IDEA
|
Currently ArcGIS Enterprise allows for authentication with an ADFS (or other SAML2) Identity Provider. The NameID is used from the SAML2 Claim to match to the name as created in Portal and gain access. If I want to authorise a user against a group, then I have to connect the ArcGIS Enterprise to the domain to determine the Enterprise Groups that the user is assigned to. It appears that a 'text match' is used to match NameIDs to the names of users retrieved from the AD Groups on a scheduled basis. The SAML specification supports a list of groups to be passed as a part of the SAML2 claim. If it was possible to create a Portal Group with a name exactly equal to the enterprise group in the claim then it 'should' be possible to string match the portal group name and the enterprise group name for use in authorising the user purely from the SAML2 claim. From a Professional Services point of view, we find ourselves deploying ArcGIS Enterprise in the cloud for customers who are exposing ADFS services, but who are not exposing their AD/LDAP to "that" cloud instance. Because of this the Enterprise Groups are not available. Presenting the Groups as a part of the SAML2 Claim would be a relatively simple way for the customer to present their Enterprise Groups to a non-AD connected ArcGIS Enterprise. We have also seen a similar issue in customers that 'zone' their networks. i.e. the AD exists in the 'corportate' domain, but the GIS is present in a DMZ where AD is not configured/available. SAML2 provides a perfect way of sharing identity, but they cannot support enterprise groups as things are implemented at the moment. While I am focussed on ArcGIS Enteprise, I believe this concept could also lend itself to well to ArcGIS Online authorisation as well.
... View more
12-07-2017
04:19 PM
|
3
|
2
|
1124
|
IDEA
|
Currently ArcGIS Enterprise allows for authentication with an ADFS (or other SAML2) Identity Provider. The NameID is used from the SAML2 Claim to match to the name as created in Portal and gain access. If I want to authorise a user against a group, then I have to connect the ArcGIS Enterprise to the domain to determine the Enterprise Groups that the user is assigned to. It appears that a 'text match' is used to match NameIDs to the names of users retrieved from the AD Groups on a scheduled basis. The SAML specification supports a list of groups to be passed as a part of the SAML2 claim. If it was possible to create a Portal Group with a name exactly equal to the enterprise group in the claim then it 'should' be possible to string match the portal group name and the enterprise group name for use in authorising the user purely from the SAML2 claim. From a Professional Services point of view, we find ourselves deploying ArcGIS Enterprise in the cloud for customers who are exposing ADFS services, but who are not exposing their AD/LDAP to "that" cloud instance. Because of this the Enterprise Groups are not available. Presenting the Groups as a part of the SAML2 Claim would be a relatively simple way for the customer to present their Enterprise Groups to a non-AD connected ArcGIS Enterprise. We have also seen a similar issue in customers that 'zone' their networks. i.e. the AD exists in the 'corportate' domain, but the GIS is present in a DMZ where AD is not configured/available. SAML2 provides a perfect way of sharing identity, but they cannot support enterprise groups as things are implemented at the moment. While I am focussed on ArcGIS Enteprise, I believe this concept could also lend itself to well to ArcGIS Online authorisation as well.
... View more
12-07-2017
04:19 PM
|
3
|
2
|
987
|
POST
|
So this is a bit of a hack, but it's what I did in my development environment. I uninstalled GeoEvent. Then logged into the admin pages of ArcGIS Server. I changed the security settings for my site and made it HTTP only. I restarted my machine. When the machine came up it was only available on HTTP (6080). I then reinstalled GeoEvent. The default 'datastore' configuration is then on the HTTP mode rather than HTTPS. This removes the SSL handshake issue. GeoEvent had all the configurations (inputs, processes, outputs) from the first install, but I needed to go through and refresh the rules that I had created inside of the filters. Not sure why that was, but everything reconnected and remained stable when only using a HTTP connection. I'm in the place where HTTP is good enough for this dataset. Before implementing this workaround you MUST be sure that HTTP traffic is enough for your site and that you will be able to support it going forward. Consider that if you're using Portal then everything should be HTTPS. There are instructions relating to SSL HandShakes here: https://community.esri.com/groups/big-data/blog/2016/07/11/troubleshooting-guide-for-arcgis-spatiotemporal-big-data-store They didn't help me as the GEE and ArcGIS Server are one and the same machine, and I could not access geoevent manager to change any of the configuration due to the error at hand. I'd welcome advise on how to fix this properly in HTTPS mode.
... View more
06-06-2017
08:34 PM
|
0
|
1
|
807
|
Title | Kudos | Posted |
---|---|---|
3 | 12-07-2017 04:19 PM | |
3 | 12-07-2017 04:19 PM |
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:24 AM
|