-
Notifications
You must be signed in to change notification settings - Fork 149
Security Concepts
This section discusses security concepts that are specific to the Geoportal Server. Overarching security concepts for an enterprise system can be found at the Esri Enterprise Resource Center security webpage.
An organization may want data to be discoverable to certain groups of people, but not discoverable to other groups. Access to metadata records can be configured in the geoportal by implementing a security policy for metadata access. The access policy chosen by the implementing organization will determine if and how a publisher can restrict access to his/her metadata. Important: Restricting user access to metadata records only restricts who can see the metadata. It does not determine user access to the actual data or web service resource itself. For more information on securing metadata please see How to Restrict Access to Resources.
Another way to secure your geoportal is to manage access through the system architecture. Three models are briefly described below.
- Public and Internal Geoportal, no public authentication: Two geoportal web applications are deployed and connect to the same database. One geoportal is public-facing, has authentication disabled so the users cannot login, and therefore provides search functionality but not publishing functions. The other geoportal is internal to the organization and has authentication configured. These registered users publish and administer the geoportal and the content that is available to the public.
- Public and Internal Geoportal, authentication enabled: Similar to the previous model, except that the public-facing geoportal supports registered users. Publisher and Administrator users access the internal geoportal.
- Public-only Geoportal, authentication enabled: The Geoportal Server Sandbox uses this model. In this case, one public-facing Geoportal is configured with authentication. Anonymous users can search the catalog and register with the geoportal. Registered users can request publishing privileges and when those privileges are granted, publish metadata to the geoportal. All users search among the published and approved metadata.
Hypertext Transfer Protocol - Secure (HTTPS) is a variant of HTTP enhanced by a security mechanism such as an encrypted Secure Sockets Layer (SSL) or Transport Layer Security (TLS) connection. It allows data sharing to take place on the internet in a protected way. The article Setting up SSL provides a good introduction to SSL and considerations for setting it up on your system. Besides general SSL configurations for your organization (see Security Resources for Geoportal System Environment Components), there are no geoportal-specific configurations required, with the exception of full URL references. For example, if you've configured a Map Viewer application to run from your geoportal under https, then it needs to be specified correctly within gpt.xml such that the URL includes the https prefix.
If you plan to have user login/logout or user/role management functionalities (e.g. through LDAP), it is recommended to use https as communication protocol to secure the user information.
This section describes some important concepts for encryption within the Geoportal Server.
In the gpt.xml file, there are sections where you can specify if the password is encrypted. When encryption is set to true, an encrypted password can be defined in these sections. To generate an encrypted password for storing passwords in the gpt.xml file, follow the steps below:
- Open the geoportal in a browser
- Log in as an administrator
- Navigate to http://<machinename></machinename>//catalog/identity/encryptPassword.page to display the Password Encryption Utility page
- Enter in your admin password into the password box
- Click the Encrypt button. The encrypted password appears in the Encrypted value box
- Copy and paste this value into your gpt.xml file where you want to encrypt the password
On the Register a resource on the network page, it is possible to define a connection to another catalog that requires a username and password. To protect the security of these remote catalogs, the Geoportal will not store the password in clear text in its database and logfiles. Instead, the Geoportal will apply an encryption algorithm to store the password. When the synchronization process uses the password information to connect to the repository, it decrypts the password. Because all Geoportal instances out-of-the-box use the same encryption key, it is important to change the value in the <enckey></enckey> section of the gpt.xml file so the encrypted passwords cannot be easily deciphered. Note: If the encryption key is changed at any point, any data already stored in the database that was encrypted with the old key will become invalid. In that case, the data will need to be re-generated and re-stored in the database to correspond to the new encryption key. For this reason it is recommended to change the encryption key at the beginning of Geoportal deployment and not change it thereafter.
To change the Encryption Key:
- Open the gpt.xml file from the \\geoportal\WEB-INF\classes\gpt\config folder in a text editor
- Scroll to the <identity></identity> tag, and note the value of encKey
- Change this value to a new key. The key can be a simple word
- Save the gpt.xml file and close it
Because the geoportal is deployed in the context of other products upon which it depends, it is important to investigate security recommendations from those other underlying technologies. Here are some useful documents that can be used for reference:
- Esri resources
- ArcGIS Resource Centers Enterprise GIS Security page
- How to Configure a reverse proxy system architecture for ArcGIS Server with an Apache Web Server
- Securing Internet connections to services
- Non-Esri resources
- Tomcat 6.0 SSL configuration: usually only necessary if Tomcat is being run as a standalone web server. If it is running behind another web server (such as Apache or IIS, as in the geoportal recommended system environment), then the SSL configuration should be on Apache or IIS and not on Tomcat.
- How To Set Up an HTTPS Service in IIS
- Apache SSL/TLS Encryption
- How to enable LDAP over SSL with a third-party certification authority