Portal to AGOL Distributed Collaboration asking for AGOL sign in.

[David_Brooks]

I'm testing setting up a Distributed Collaboration with a consultant organisation. They are the host, as they have AGOL, and we are a guest as we have Portal.

We set up the collaboration so that the Guest receives content only. The Host tested adding a csv file to the collaboration group and I was able to download it from the Guest group with no issues.

However, when they added a Hosted Feature Service to the group (empty, shared only to the group), I (as the guest) am prompted to log into ArcGIS Online in order to access the item:

A quick check on the ESR workflow and I found this section on Copy vs Reference:

https://doc.arcgis.com/en/arcgis-online/administer/create-a-collaboration.htm

Choose one of the following to specify how hosted feature layers will be sent to the collaboration workspace:

• References—Collaboration participants will receive live access to feature layers. If the item is secured (not shared with everyone), users must sign in to the origin environment to access the item.
• Copies—Collaboration participants will receive a copy of the feature layer, and updates from the origin will be synchronized at a scheduled interval defined by the guest.

  Note:

  If you choose this option, the collaboration guest must set a sync interval in the collaboration workspace, and sync must be enabled on each item in the collaboration. A copy of the feature layer and its data will be extracted and published as an item in each recipient's environment. Once the item has been created, subsequent synchronizations will only sync updates of that item.

Am I missing something here? Or is this red text essentially telling me that Guests can't access Host content as References unless they have login credentials for the Host organisation or if the layer has Public access enabled? If so, what on earth is the point in Distributed Collaborations??

Furthermore, if the only option that works is to set layers as Copies rather than References, then we'll be duplicating the data and increasing the load on our Portal, negating the benefit of the Collaboration in the first place. If I wanted to copy data, then I could just use AGOL Assistant.

Surely I'm missing a key point here?

[ZacharyHart]

If so, what on earth is the point in Distributed Collaborations??

@David_BrooksI kid you not I am in the middle of writing a nearly exact post to Geonet in this very same forum right now. You're summarizing all my concerns exactly.

After much research (and for various reason) our organization needs to implement a AGO-Enterprise hybrid environment (for our organization only). After creating the collaboration I too discovered that trying to access a referenced service layer from AGO would prompt for our Enterprise authentication as well. Note, this isn't just for HFLs or referenced (eGDB) feature layers; this happens for simple map image layer as well.

Now, in our case, we could configure SSO on both sites for our users, but that would mean you'd need to have the user assigned to both AGO & Enterprise (2 licenses for each user). Am I missing something here?

Right now I've lost site of what the benefits of the collaboration are if this cannot be resolved. 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?

[David_Brooks]

@ZacharyHart exactly! 

We were looking at this as a way of collaborating with many consultant organisations, who all have AGOL and want to share their content with us for QA/QC. Since posting the above, I have now discovered that a Portal can only have one collaboration with an AGOL Org

As far as I can tell, this isn't documented anywhere...

...So it would seem that my best alternative would be to give all QA/QC users AGOL Viewer accounts, and then ask the consultant organisations to add these viewers to their AGOL Groups. Not really what we had in mind.

I did wander if it was possible to have an AGOL organisation as a Host, which we use with partnered collaborations with our consultants, and then access the Partnered Collab layers via the distributed collaboration on our Portal, but I highly doubt this would work.

[ZacharyHart]

While our use cases are different, we definitely have overlapping concerns, so i proceeded to start another thread for visibility.

[ZacharyHart]

@David_Brooks 

Relevant I'd say:

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

[DavidColey]

Hello - 

I have 17 collaborations set up between our Enterprise portal (guest) and our ArcGIS Online org (host)., for about 7 yeas now. All of the collaborations are by reference.  As a county government, we have to provide data, and so for us, this means I can manage all of our layers in Enterprise and then send them to our ArcGIS Online org in the collaborations' groups, where those groups are part of our Hub / Open Data site.

All of the layers that participate in the Open Data site are shared publicly in Enterprise, and the share level of the ArcGIS Online, by-reference version of the layer is also public, as are the AGOL groups that participate in the Open Data site.  In this way, no login prompts are ever displayed. We protect the Enterprise by not allowing anonymous access, and by disabling the Hosting site REST directory. 

We chose not to collaborate webmaps (for say basemaps) but just the layers to make the basemap for the AGOL side. Nor do we have any Enterprise Configurable or Instant Apps that participate. We DO have Enterprise-registered, WAB developer-edition apps and  Enterprise-registered, JavaScript api apps that do participate in a collaboration.  

I also have a collaboration where I am sending content from our Org to the Enterprise.  If the Org layer is public, then no login prompt is asked for the Enterprise user, but you have to be signed into the Enterprise. If I don't want the Org layer shared with the public, then yes - the Enterprise user will have to provide their AGOL login.  All of this by design.

More:  the reason we use by-reference collaborations is due to how we manage data to keep it updated for the public:  GIS staff update layers in an SDE traditional  version space, we extract to file gdb via python and upload/overwrite SD-generated hosted layers via the arcpy sharing module. 

We don't use the as-copies model because the as-copies model requires that the hosted layer have editing and sync enabled (as shown earlier) but that means the hosted layer is never over-written.  Should you want to use the as-copies model, then you are then instead setting up a workflow where the hosted layer is the edit layer, and edits are synced at maybe a shorter interval.

Point is, we and I went through all of this pain to make this work precisely because we no longer wanted to use the add-item, stored credential method for several hundred layers.  And although the arcgis api will let you script doing that (now, but not when we started this) you are still adding performance overhead as the layer has to go through the ArcGIS Online proxy to read those stored credentials every time the layer is accessed.

Hope this helps. 

[David_Brooks]

@DavidColey ah that sounds like you're using collaborations to excellent effect. Unfortunately for us, all our services have strict group sharing, so it's rendered the whole endeavour obsolete.

Im now wandering, if we have a single user AGOL org that could act as a host, whether we could use that to create Partnered Collaborations, and then consume the services that way

[DavidColey]

Yes hello @David_Brooks - I don't know how that would help you, unless you don't belong to an existing agol org.  Because even in a partnered collab there will still be sign-in prompts for layers depending on their share level, whether as-copies or by-reference. It really comes down to workflows and trust. 

One thing you could do would be to have the agol org host that you are working with add you and members of your team to their agol org (without using up their seats as long you have an agol org) - i.e they add you to their agol org using your orgs agol credentials. 

That way, when you get the prompt, you login using your own agol credentials. 

Another thing you could explore: If the collab is a send and receive workflow you could try setting up the participating group or groups as shared update groups.