Skip To Content

Identity Components: LDAP and Single Sign-On

Identity Components: LDAP and Single Sign-On

The Geoportal implements a standard Java container-based authentication pattern. The Java container is configured to authenticate against an identity store. Inbound requests are processed by the container and credentials are requested for and authenticated as required. Information about the authenticated user is then supplied, per request, to each participating web application running within the container. This information is supplied as a UserPrincipal object, which typically holds a "username" credential; the "password" credential is not provided to the underlying applications.

At a minimum, the Geoportal requires read access to an external LDAP (Lightweight Directory Access Protocol) identity store. The identity store holds information about users and groups. A set of functions query the identity store (read only) to determine the attributes associated with a user (e.g. E-Mail address), the groups to which a user belongs, and the groups within the store. Authorized access to specific functionality is based upon group membership (i.e. role), defined below:

  • Geoportal Administrator : group members have full access, including the ability to approve metadata documents
  • Geoportal Publisher: group members can publish metadata documents and register remote sites for harvesting
  • Geoportal RegisteredUser : group members can save searches and maps for later use
A set of functions edit the content of the identity store. These functions are related to user management and include: the ability to register as a member, user profile management (edit LDAP user attributes such as E-Mail address), change password, and forgot password. These functions can be disabled in the gpt.xml configuration file in cases where a writable connection to LDAP is not available or desired. The Geoportal implements LDAP communication through an extensible class, com.esri.Geoportal.framework.security.identity.ldap.LdapIdentityAdapter. If required, this class can be overridden to provide custom behavior. However, in most cases integration with an organization's LDAP can be configured through the <identity> section of the gpt.xml file without changing the classes.