Back to Top

ArcGIS authentication models and providers

ArcGIS is built with, supports, and evolves with standard IT industry authentication mechanisms, protocols, and technologies to ensure it integrates smoothly with an existing organization’s security policies, practices, and infrastructure. ArcGIS products follow standard authentication practices when accessing IT resources, including file sources, DBMS sources, and web-based sources.  ArcGIS Enterprise and ArcGIS Online both support a built-in user store as well as standard user stores and identity providers (IdP) that IT organizations use and provide, like Microsoft Active Directory, LDAP, Okta, and others. ArcGIS clients and servers support authentication across every tier in a single or multi-tier architecture, including ArcGIS clients or servers accessing web services, portals, DBMS(s), file stores, data lakes, and other sources.

ArcGIS also supports and promotes single sign-on (SSO) user authentication experiences that rely on an organization’s existing Identity Provider (IdP) and security infrastructure to manage user identities and credentials and authentication mechanisms.  Integrating with IdPs in this way ensures that ArcGIS seamlessly builds on established mission-critical security infrastructure with robust, centralized user provisioning, administration, monitoring, and auditing resources.

User authentication protocols and mechanisms in ArcGIS

To establish a user or programmatic session with ArcGIS Enterprise or ArcGIS Online, the following supported standard industry protocols and mechanisms are used to authenticate users and clients across the ArcGIS system. They include:

ArcGIS also supports anonymous user access to most resource types across the system, for organizations which have a requirement for either open access on their WAN, or public access to applications through the internet.

  1. Supported in ArcGIS Enterprise only ↩ ↩2

  2. API keys are only supported with ArcGIS Platform ↩

Identity providers

ArcGIS supports and integrates with an organization’s existing identity provider (IdP) based on the supported authentication protocols provided above, such as SAML, IWA/AD, LDAP, or PKI. This integrated approach simplifies the security model and allows ArcGIS to rely on the IdP to directly authenticate users, provide authentication services, manage access (for example, to add or remove privileges or enable or disable accounts), and provide single sign-on (SSO) user experience as well as vulnerability and intrusion prevention resources. Lastly, ArcGIS can integrate with network and cloud based IdPs depending on the authentication protocol(s) supported in the IdP.

Identity in ArcGIS

When using web-based resources in ArcGIS, a user establishes an identity after they initially authenticate. Identity can be established through the variety of methods, but the general sequence is described as follows:

  1. A user can initiate a login through an ArcGIS sign in dialog or when they are prompted to “log in”, for example, when accessing a secured resource.
  2. An ArcGIS sign in prompt may appear as a redirect, popup or embed. Available login options for that specific ArcGIS Enterprise deployment or ArcGIS Online organization will be presented, allowing the user to choose an option or instead, present the only available option if only one is enabled. This sign in window and underlying process are based on OAuth standards, and as such, there are also scenarios when a user might be asked to approve access to an external application, as is the case in other OAuth workflows used by other applications or systems.
  3. In a direct login configuration, the user authenticates directly with a built-in user, AD or LDAP-based account, and receives an OAuth code, which is exchanged for a session token. The popup or browser interface generally handles this process, and the user is then returned to the originally requested page or application.
  4. Alternatively, the user may choose to login through a SAML or OIDC Identity Provider. In doing so, they will click a button which triggers a login process to that IdP. Each IdP is configured differently and can support a wide variety of authentication patterns. Successful authentication to that IdP will return the user to ArcGIS with either a SAML Assertion or an OIDC claim that identifies the user as a valid user from the IDP’s perspective (approved for that application and properly authenticated). At this point, ArcGIS generates an OAuth code and subsequent ArcGIS session token for the user, who can then access the desired applications or services.

However authentication is completed, the resulting session is based on the ArcGIS access token. This token is maintained either in application code or as an HTTP cookie and is valid for a specific duration and session. The default token expiration is 120 minutes, though tokens can be refreshed. The user’s identity also includes user-specific attributes that apply across the ArcGIS system and user experience, such as:

  • User type – such as Viewer, Editor, Creator or other
  • User role – such as Publisher, Administrator, Custom or other
  • Authorized licenses
  • Various privileges that are set from role-based access controls, such as group membership

Along with the access token, a refresh_token is also generated, which can be used to refresh the user’s access token and extend their session when usage goes beyond a two-hour period.

When using desktop-based resources in a traditional client-server configuration, for example, DBMS or file server, the user’s identity is based on the security model associated to the server technology or operating system capability.

In backend automation scenarios, like server-to-server or operating system process-based communications, the client in those interactions follows the patterns above to establish identity with associated credentials.

Further information on ArcGIS-specific authentication patterns can be found on the ArcGIS Developers site.

Server-to-server authentication

While most use workflows completed in ArcGIS systems are user-based, where a person is interacting with a web page or application that issues requests to a server, other workflows require a server-to-server or programmatic level of interaction, whether for integrating between systems, automating data tasks, or providing some other level of connectivity between different server-like or backend systems.

While server-based requests that allow an anonymous identity are simple to support, there are many options for authenticating these requests when the service or endpoint is secured, and some level of authentication or identification is required. Some general recommendations in this area include:

  • Most server-to-server communications cannot use a SAML-based or OIDC-based authentication pattern as these IdPs require interactive login experiences using an HTML interface, and often include multifactor authentication prompts or captcha-style validation.
  • Requests that originate from within a geoprocessing tool or scheduled script tool running on a server will assume the identity of the service account or local account running that process. Especially with IWA-based scenarios, the identity and settings for this user account can significantly affect the success of a server-side request.
  • The use of an ArcGIS OAuth-based refresh_token (generated from a built in or enterprise identity provider), can be embedded in a system and used to generate session tokens on an as-needed basis. A valid refresh token can also be exchanged for a new refresh token, so logic can be created to maintain this refresh token and keep it valid indefinitely.
  • API keys (currently available in ArcGIS Platform) are another potential method to authenticate server-side processes, where an API key can be generated for a specific service and workflow and used by a server-side process to authenticate and perform certain operations such as geocoding or routing requests.
Top