ArcGIS is built with, supports, and evolves with standard IT 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 secured 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 a variety of enterprise identity providers (IdPs) that IT organizations use and provide, like Microsoft Entra ID, Active Directory or Okta. ArcGIS clients and servers support authentication across every tier in a single or multi-tier architecture, including accessing web services, portals, DBMSs, file stores, data lakes, and other sources. This topic will provide further details on authentication processes and options that are considered during an architecture design process.
ArcGIS supports and promotes single sign-on (SSO) user authentication experiences that rely on an organization’s existing IdP and associated 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. ArcGIS integrates with an organization’s IdP through widely-accepted authentication patterns, such as SAML, OIDC, 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.
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:
However authentication is completed, the resulting user session is based exclusively on the ArcGIS access token. This token is maintained either in application code or stored and communicated as an HTTP cookie and is valid for a specific duration. The default token expiration is 120 minutes, though tokens can be refreshed and requested for longer periods. 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.
A user identity also includes user-specific attributes that apply across the ArcGIS system and user experience, such as their:
When using desktop-based resources in a traditional client-server configuration such as a 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 Esri Developer site.
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:
Esri provides support for SAML-based logins in ArcGIS Enterprise and ArcGIS Online along with a set of identity provider-specific documentation. OpenID Connect (OIDC) is also fully supported for ArcGIS Enterprise and ArcGIS Online organizations. Esri recommends the use of SAML or OIDC logins for all organizations where this option is available.
In the context of ArcGIS, both SAML and OIDC facilitate secure access by enabling users to sign in using their existing credentials from a trusted identity providers, such as Google, Microsoft Entra ID, Okta or other enterprise identity systems. When a user attempts to access an ArcGIS system without a current authentication session, they are redirected to the identity provider to authenticate. The identity provider handles the authentication step, where a username, password, one-time code or other factors are provided to the system, and if successful, the identity provider issues a SAML assertion or OIDC claim, which is sent back to ArcGIS to validate the user’s identity.
Benefits of using SAML or OIDC include:
How it works
The built-in identity store allows you to manage users and groups directly within the ArcGIS Server components or Portal for ArcGIS. This means you don’t need an external system to handle user authentication. ArcGIS takes care of the authentication process, verifying usernames and passwords stored within its own database. This method is often used for initial setup, development, and testing because it allows for quick and easy account creation.
Practical Example
Imagine you’re setting up a new ArcGIS Enterprise portal for a small team of GIS professionals. You can quickly create user accounts for each team member directly in the portal. Each user can then log in with their credentials to access maps, apps, and other resources shared within the organization.
Advantages
Ease of Use - No need for complex integration with external systems.
Quick Setup - Ideal for getting started quickly, especially in development and testing environments.
Self-contained - All user data is managed within the portal, simplifying administration.
Limitations
Scalability - Not ideal for medium to large organizations with many users, as it can become cumbersome to manage.
Security - May not meet the stringent security requirements of some organizations compared to using LDAP or SAML.
Integrated Windows Authentication (IWA) and Active Directory (AD) and Lightweight Directory Access Protocol (LDAP) protocols, which are only available with ArcGIS Enterprise, are commonly used within organizations for internal-facing or on-network workflows. Esri only recommends use of IWA, AD and LDAP configurations for internal-facing deployments of ArcGIS Enterprise.
Public Key Infrastructure (PKI) using client certificates is used across several authentication patterns, including IWA, SAML and OIDC.
Multi-Factor Authentication (MFA), is often applied to ArcGIS built-in logins or applied as part of a SAML or OIDC process using an external identity provider. This is a recommended best practices, especially for highly-privileged accounts.
Application-based authentication is another pattern of authentication, related to the built-in user pattern, where authentication is completed using API Keys or client ID and client secret pairs.1
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.
API keys are supported with ArcGIS Location Platform, ArcGIS Online and ArcGIS Enterprise at version 11.4 or later. ↩
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:
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.