Hello, I am having problems accessing secured services in the Collector app for iOS. I've tested my environment in the Android version, and everything works fine. Here is my environment:
When I open the map, I am never prompted for my credentials again. The app behaves as if everything is working fine. My layers are listed in the Layer List with the option to turn them off and on, but none of them ever display in the map.
Any ideas why this is happening?
let me say that this is also happening in the Explorer app as well. So, maybe I'm missing something about how this is supposed to work in iOS in general.
Going to assume issue is Web-Tier Auth. This requires additional configuration under security settings on AGOL side. Need to leverage the Trusted Servers in order to use Web-Tier. These contain details about configuring, passing credentials, etc.
Thanks, Scott. I've already listed my serve site as a Trusted Server in my organization settings. The format should simply be "https://webserver.domain.com", correct? Wouldn't the Trusted Server issue be affecting android as well? Collector is working fine when I test in android. After opening a map, it asks me for credentials. If I choose to let it remember me, it will apply those credentials to the remaining features in the map. Works great. In the iOS Collector app, i'm never given the chance to send my ArcGIS Server credentials from AGO.
Hmmm, yeah we have seen differences between iOS and Android across lots of things but the certificates have been consistent on both with the few hiccups we had. I can say that our experience has been that iOS doesn't play well with SSL offloading and we had to disable it then provide the full root, intermediate and wildcard certs we use on all our clustered machines.
We haven't begun testing the Trusted Server option yet and are still using token based auth. Done the research on it all and we plan to test it soon. Based off the documentation I believe your format is correct and would be expected otherwise it makes clustered environments a pain.
I can't say off top of my head anything else that would cause this. Actually re-reading it, while iOS isn't working it sounds like Android is also not working. My understanding of the use of the Trusted Servers option is the user shouldn't be required to enter the credentials a second time. It's supposed to provide a SSO experience. So it sounds as though the user is doing the AGO sign in and in Android incorrectly being prompted to login in based off the security on the REST services coming through the map rather than the users credentials automatically being passed through from back when they signed into Collector via Enterprise login option. If this is the case, then potentially the Trusted Server configuration is off or simply isn't working and explains why iOS appears to be incorrectly broken but truly is broken. Perhaps experiment with the Trusted Server URL by adding ports?
Sorry, again not having fully implemented this I can't speak to any issues we encountered just going off all the research I've done in prep for our test environment to change over.
Thanks for the info, Scott. After working with customer support for a while on this, I was ultimately told it is a bug.
"BUG-000095632 : Some ArcGIS Server web tier secured services do not lead to a credentials challenge in Collector for ArcGIS 10.3.9 (iOS). The challenge is seen for the same REST URL in Safari on iOS devices."
I'm on 10.4 Collector, and I only get the challenge in Safari if I don't have my web adaptor machine listed as a trusted server in my org settings in AGO. But, maybe the bug does apply to me. I'm told to wait for the 10.4.1 update to see if it addresses my issue. Until then, we are going with GIS Tier.
As to your question about iOS behaving properly but trusted server config causing the hangup, I'm told the behavior in Android is the expected behavior. I don't think the trusted server is intended to give a SSO experience. It's just there to have permission to pass the credentials you've provided when needed.
Interesting and good to know. So from your original post we have an identical architecture to what you are running with a SQL2012 DB on the backend. The only variation is that we stuck with GIS tier.
We saw a similar issue with non-displaying layers to what you initially described but I can't recall which of 3 possible issues was tied to resolving it.
1) We have a BigIP in play where we assign the VIP to load balance onto our IIS Web Servers in the DMZ. The BigIP had some caching turned on that we had to tweak at one point. We also have found that making significant web adaptor or ArcServer configuration changes requires us to turn off all the BigIP caching and then turn it back on.
2) The certificates while maybe not necessary we fully deployed to 3 locations: a) within Windows Certificate Manager on both the IIS Web Server ensure the Root, Intermediate and Personal Certificates are installed; b) do the same thing in A but on the servers hosting ArcGIS Server; c) from the Admin Directory http://<server_name>.<domain>:6080/arcgis/admin/login add all 3 certs to each machine
3) We have a need to allow Collector Access over our wifi network which is different from our hard line network. This was tied to networking and BigIP items but we had to create some specific iRules to allow proper access and once that was done we had to exclude the VIP we are using from the BigIP list for SSL offloading (i.e. we wanted our servers to handle it rather than the BigIP handling it).
Side item, in a recent convo with ESRI we were able to establish that it is their understanding that there is no scenario which will offer an SSO experience other than using Portal instead of AGO. Essentially, they stated that because the user Enterprise login is derived from ADFS in AGO and either the Web Server or ArcServer is hitting AD directly it gets handled as a mismatch. By that, ESRI stated the returns from ADFS if they were passed to the servers on backend even though username/password are identical it's a different format so the backend servers will always cause a prompt. We are going to investigate a work around to this which would involve using a service account as the controlling factor for securing the REST service but then during publishing to AGO choose to store the username/password combo into AGO and then it's just managing control to that REST service in AGO products that use it via group controls, etc.
Any luck with SSO in Collector? I was told by ESRI that SSO is not supported in Collector App. I have a federated Portal setup, SSO, IWA, AD on IIS. Was curious if anyone got this to work, otherwise Collector is useless in our environment, what a shame.