The primary factor you should use to determine how you configure security in your Portal for ArcGIS deployment is the source of users and, optionally, groups for your portal. This source of users and groups is called your identity store. Users and groups within or outside your organization are managed through the identity store.
- Understanding identity stores
- Configuring built-in users using the portal's identity store
- Configuring enterprise logins using web-tier authentication
- Configuring enterprise logins using SAML
Understanding identity stores
The identity store for your portal defines where the credentials of your portal accounts are stored, how authentication occurs, and how group membership is managed. The ArcGIS Enterprise portal supports two types of identity stores: built-in and enterprise.
Built-in identity store
The ArcGIS Enterprise portal can be configured to allow members to easily create accounts and groups in your portal. When enabled, you can use the Create an account link on the portal website Sign In page to add a built-in account to your portal and start contributing content to the organization or access resources created by other members. You can also click the Groups tab on the portal website home page and create a group to manage items. When you create accounts and groups in your portal this way, you are leveraging the built-in identity store, which performs authentication and stores portal account user names, passwords, roles, and group membership.
You must use the built-in identity store to create the initial administrator account for your portal, but you can later switch to an enterprise identity store. The built-in identity store is useful to get your portal up and running, and also for development and testing. However, production environments typically leverage an enterprise identity store.
Enterprise identity store
The ArcGIS Enterprise portal is designed so you can use enterprise accounts and groups to control access to your ArcGIS organization. For example, you can control access to the portal by using credentials from your Lightweight Directory Access Protocol (LDAP) server and identity providers that support Security Assertion Markup Language (SAML) 2.0 Web Single Sign On. This process is described throughout the documentation as setting up enterprise logins.
The advantage of this approach is that you do not need to create additional accounts within the portal. Members use the login that is already set up within the enterprise identity store. The management of account credentials is completely external to the portal. This enables a single sign-on experience so users will not need to reenter their credentials.
Similarly, you can also create groups in the portal that leverage the existing enterprise groups in your identity store. Also, enterprise accounts can be added in bulk from the enterprise groups in your organization. When members log in to the portal, access to content, items, and data are controlled by the membership rules defined in the enterprise group. The management of group membership is completely external to the portal.
For example, a recommended practice is to disable anonymous access to your portal, connect your portal to the desired enterprise groups in your organization, and add the enterprise accounts based on those groups. In this manner, you restrict access to the portal based on specific enterprise groups within your organization.
Use an enterprise identity store if your organization wants to set policies for password expiration and complexity, control access using existing enterprise groups, or leverage authentication over LDAP or Public Key Infrastructure (PKI). Authentication can be handled at the web-tier (using web-tier authentication), at the portal-tier (using portal-tier authentication), or through an external identity provider (using SAML).
Supporting multiple identity stores
Using SAML 2.0, you can allow access to your portal using multiple identity stores. Users can sign in with built-in accounts and accounts managed in multiple SAML-compliant identity providers configured to trust one another. This is a good way to manage users that may reside within or outside your organization. For full details, see Configuring a SAML-compliant identity provider with your portal.
Configuring built-in users and groups using the portal's identity store
No steps are necessary to configure the portal when using built-in users and groups; the portal is ready for built-in users and groups immediately after installing the software. If you are using enterprise users, see the following sections and related links for more information.
Configuring enterprise logins
The following enterprise identity providers can be configured with the portal. Authentication can be handled at the web tier (using ArcGIS Web Adaptor) or at the portal tier.
If you have an LDAP directory, you can use it with the ArcGIS Enterprise portal. See Using your portal with LDAP and web-tier authentication for more information. If you want to use LDAP, deploy your Web Adaptor to a Java application server such as Apache Tomcat, IBM WebSphere, or Oracle WebLogic.
If your organization has a PKI, you can use certificates to authenticate communication with your portal using HTTPS. It is not possible to enable anonymous access to your portal when using PKI. See Using LDAP and PKI to secure access to your portal for more information.
If you want to allow access to your portal using both enterprise and built-in identity stores without using SAML, you can use portal-tier authentication. This is achieved by configuring the portal with your LDAP identity store, then enabling anonymous access in your Java application server. When a user accesses the portal sign-in page, they will be able to log in using either enterprise credentials or built-in credentials. Enterprise users will be required to enter their account credentials each time they log in to the portal; automatic or single-sign on will not be available. This type of authentication also allows anonymous users access to maps or other portal resources that are shared with everyone.
When using portal-tier authentication, members in your enterprise will log in using the following syntax:
- If using the portal with your Active Directory, the syntax can be domain\username or username@domain. Regardless of how the member logs in, the username always displays as username@domain in the portal website.
- If using the portal with LDAP, the syntax is always username. The portal website also displays the account in this format.
Configuring enterprise logins using SAML
The ArcGIS Enterprise portal supports all SAML-compliant identity providers. The following tutorials demonstrate how to configure certain common SAML-compliant identity providers with the portal. For more information, see Configuring a SAML-compliant identity provider with your portal.
Account lockout policy
Software systems often enforce an account lockout policy to protect against mass automated attempts to guess a user's password. If a user makes a certain number of failed login attempts within a particular time interval, they may be denied further attempts for a designated time period. These policies are balanced against the reality that sometimes users will forget their names and passwords and fail to log in successfully.
The lockout policy enforced by Portal for ArcGIS depends on which type of identity store you're using:
Built-in identity store
The built-in identity store locks out a user after five consecutive invalid attempts. The lockout lasts for 15 minutes. This policy applies to all accounts in the identity store, including the initial administrator account. This policy cannot be modified or replaced.
Enterprise identity store
When you're using an enterprise identity store, the account lockout policy is inherited from the store. You may be able to modify the account lockout policy for the store. Consult the documentation specific to the store type to learn how to change the account lockout policy.
Monitor failed login attempts
You can monitor failed login attempts by viewing the portal logs in the Portal Directory. Any failed attempts result in a warning-level message stating that the user failed to log in because of an invalid username or password combination. If the user exceeds the maximum number of login attempts, a severe-level message is logged stating that the account has been locked out. Monitoring the portal logs for failed login attempts can help you understand if there is a potential password attack on your system.
For more information, see Work with portal logs.