AGO Enterprise Distributed Collaboration Secured Services

[ZacharyHart]

Note: This primarily concerns referenced map image layers & imagery layers.

With distributed collaboration, you can extend the reach of your GIS content by seamlessly sharing maps, apps, layers, and more with other organizations

(emphasis added)

I have successfully created a distributed collaboration between our ArcGIS Online organization and our ArcGIS Enterprise site. If I share layers to the workspace they appear in AGO just fine but when attempting to access the services, I'm prompted to log into our Enterprise site.

Doesn't this defeat the purpose of a collaboration? Why wouldn't I just manually add content to AGO from URLs from our Enterprise site and just embed/store the credentials in the item?

[Scott_Tansley]

Hey, can you just double check the instructions here???:

https://enterprise.arcgis.com/en/portal/latest/administer/linux/manage-collaborations-as-guest.htm#:.... 

When you 'copy' you're sending the data to their Enterprise or to an AGOL 'portal', that uses the entirety of the remote security model.

When you share by 'reference' then their security model allows discovery and access to the 'outer' endpoint of your referenced map image layer (or whatever service type it is).  However, that endpoint will ask your portal to ask 'Who you are'.  So, you can embed an inbuilt viewer user to the configuration of the DC.  T

This user remains within your DC configuration.  When your server says "who are you" then it will check with the DC, and find the credentials and then let you in.   If there is no embedded credentials, then the 'end user' will be asked to sign in.

This approach keeps all credentials within your control, so you can remove/change them and never give them to the remote portal/AGOL.  It's a safer approach than getting them to register your endpoint as an item in their portal and then saving the credentials you give them.  

Ultimately if you're sharing by reference and your item is secure then it must have authentication and the DC effectively becomes the user and passes that goodness on to the remote portal.

Sorry, tricky to explain, but I hope the instructions help?

[ZacharyHart]

@Scott_TansleyI have read that documentation.

Add Viewer credentials to a workspace

More here:
https://www.esri.com/arcgis-blog/products/arcgis-enterprise/sharing-collaboration/whats-new-in-arcgi...

[Scott_Tansley]

Top tip.  Thanks for sharing.  Most of my work is enterprise to enterprise rather than AGO.  Good information, sorry I didn’t help. 

[ttimmerman_nes]

Hey @ZacharyHart ,

This is the intended functionality of a distributed collaboration. The only way to overcome the credentials prompt is to use create a distributed collaboration which is configured to share as copies (Create a distributed collaboration—Portal for ArcGIS | Documentation for ArcGIS Enterprise, see step 7). If configured this way, the resulting service URLs in AGOL will not directly reference the ArcGIS Enterprise service URL and will instead use an AGOL service URL. The share as copies functionality relies on the sync capability of feature services, so you'll have to make sure the services which you choose to share across the collaboration, and the underlying datasets, meet the associated requirements. 

In terms of why you would choose to use a distributed collaboration rather than just storing services in AGOL with credentials, I would say the main benefit is visibility. You can always refence the group associated with the workspace on both sides of the collaboration to easily keep track of which AGOL items ultimately reference which ArcGIS Server service. 

Hope this helps.