One of our customers use ArcGIS Online organizations and configure their logins with Active Directory, they create web maps using ArcGIS server services layers, this services are secured with the same enterprise identity, when they open web maps it request the ArcGIS server Services login, Can they configure AGOL for they don't have to write twice their login and password?
We are stuck in the same situation. The ADFS credentials are not being passed through to ArcGIS Server and so secured services are issuing a challenge a second time.
I would really appreciate feedback from folks who have successfully implemented this.
Even though you're signing in with your active directory credentials, I'm pretty sure requests to services in webmaps won't use those same credentials. If you're interested in avoiding prompts for security, then you should embed credentials within the service items. Note this does not work with web tier security.
Add items—ArcGIS Online Help | ArcGIS - See step 5
As one of the comments already suggest:
Enabling Enterprise Login (SAML) for AGOL simply enables SSO into the AGOL platform. If one of the map services in one of the AGOL Webmaps is consuming a secured AGS map service (which is using Integrated Windows Authentication) that is going to invoke another sign-in request (this is IIS raising an LDAP authentication login and has nothing to do with your ADFS login you did previously, even though they both point to the same AD identity store).
Thankfully all modern browsers are capable of recognizing such login request so what you need to do is on the client web browser automatically pass the logged in credentials. In IE you can do this through Internet Options->Security->Local Intranet->Custom Level->User Authentication->Automatic Logon with current name and pass:
FF, Chrome have similar settings.
1. There are still two authentications happening, 1 through ADFS to login to AGOL and 2 through IIS
2. Only do this when users are accessing these services from within the LAN (or VPN-ed). Your IT department might not like / allow the second type of authentication happening over the internet. That protocol is not secured...
We are also struggling with this. We have public facing services that require security for various reasons (data confidentiality or integrity) The primary workflow would be for 'Collector for ArcGIS'. We would like to host on-premise services that are accessible in our ArcGIS.com solution.
An alternative we are mulling around is to deploy a public facing on-premise 'portal for arcgis' solution, and federate our ArcGIS Server solutions to that. Unfortunately having multiple portals is very cumbersome and confusing by end users and adds additional IT burden. We would have to manage users, groups, and items in two different public portals to provide secured access to both services and portal items (eg: web-maps/apps)
We started an Ideas post ( ) for Esri to consider allowing on-premise ArcGIS Server to federate with an ArcGIS Online portal. This would allow our ArcGIS server environments to inherit the security settings (authentication/authorization) with the portal and leverage the same single-sign-on session.
If this were implemented - For your case, I expect you would share your service with the same arcgis online group as your web-map. Users that are members of that group would get authorized access to both resources (the service and web-map).
My plug - You may consider to 'vote up' !
This is something ESRI has had in place for a little while, maybe a year or so. We use ADFS and sounds like you probably would as well but there are a few other options and I can say we briefly tested the 2 factor auth that can be enabled in AGO with ADFS in place and it worked out fine.
So we haven't gone into testing on this as of yet but has anyone tried out the new "Trusted Servers" feature in AGOL for use with web-tier authentication (URL and copied details below) as this would seem to solve the problems as long as you are working with a single AD forest?
I know we were interested to hear that we would at least be able to switch over to web-tier for our Collector projects but not sure that this will resolve the dual authentication prompts from iPads. I've already had to explain to our users that from desktops we can't pull in their windows credentials to pass through because we run 2 AD forests (internal and external) with a 1 way trust where external trusts internal but internal doesn't trust external. We've had to build out our solution using the external to facilitate usage by contractors along with internal users but it has created some frustrations for internal users having to create/use secondary AD account/password combos along with having to enter the external creds from desktops since their internals can't be authenticated form local system login. Unfortunately, after over a month working with various levels of the ESRI support staff we have learned that there is zero planned intention for ESRI to modify ArcServer to be able to support multiple forests so our last hope is we've found a workaround in ADFS that's allowed us to auth both internal and external into AGOL from the single external ADFS instance and we are hoping to create something that allows us to trick ArcServer and make this work as well, possibly using an LDAP config over Windows Domain config.
For Trusted Servers, configure the list of trusted servers you wish your clients to send credentials to when making Cross-Origin Resource Sharing (CORS) requests to access services secured with web-tier authentication. This applies primarily to editing secure feature services from a stand-alone (unfederated) ArcGIS Server or viewing secure OGC services. ArcGIS Servers hosting services secured with token-based security do not need to be added to this list. Servers added to the trusted servers list must support CORS. Layers hosted on servers without CORS support may not function as expected. ArcGIS Server supports CORS by default at versions 10.1 and later. To configure CORS on non-ArcGIS servers, please refer to the vendor documentation for the web server.
The host names need to be entered individually. Wildcards cannot be used and are not accepted. The host name can be entered with or without the protocol in front of it. For example, the host name secure.esri.com can be entered as secure.esri.com or https://secure.esri.com.
Editing feature services secured with web-tier authentication requires a web browser enabled with Cross-Origin Resource Sharing (CORS). The latest versions of Firefox, Chrome, Safari, and Internet Explorer 10 and later are CORS enabled. CORS is not supported in IE earlier than version 10. To test if your browser has CORS enabled, open http://caniuse.com/cors.