This chapter identifies best practices for securing your OpenAM deployment.
OpenAM includes default settings to make it easier for you to evaluate the software. Avoid these default settings in production deployments.
When connecting to LDAP, bind with a specific administrative account rather than a root DN account if possible.
Change the default
iPlanetDirectoryProcookie name both in OpenAM (com.iplanet.am.cookie.name) and in your policy agent profiles (com.sun.identity.agents.config.cookie.name).When installing OpenAM, do not use
/openamor/openssoas the deployment URI.Set valid goto URL domains for OpenAM in the core authentication module configuration. The parameter is described in the section providing Hints For the Core Authentication Module (
iplanet-am-auth-valid-goto-domains).Create an administrator in the top-level realm with a different ID than the default
amadmin.Create specific administrator users to track better who makes configuration changes.
Set the OpenAM advanced property
openam.auth.soap.rest.generic.authentication.exceptiontotrue. This causes OpenAM to return the same exception both when the user does not exist, and also when the password is not valid.
Anytime users interact with a web service, there are risks. With OpenAM, you can reduce those risks by deploying different parts of OpenAM in appropriate parts of an enterprise network.
To minimize risks, deploy only the core OpenAM server on systems directly connected through a firewall. As a start, deploy only the core server (and the protected web application) on Internet-facing servers. For instructions, see the following section from the OpenAM Installation Guide, Determine Which War File to Deploy.
You can further limit what is exposed through the firewall by using one of two strategies:
Set up a distributed authentication user interface (UI) in a DMZ between firewalls.
The distributed authentication UI is essentially a small subset of the OpenAM server with just enough login logic to receive user authentication requests. Those requests are forwarded to the core OpenAM servers.
See Installing OpenAM Distributed Authentication for installation instructions. The following figure shows the recommended architecture.
Alternatively, use a reverse proxy in front of OpenAM to allow access only to the necessary URLs. The following figure shows the recommended architecture with a reverse proxy.
For access to the console, deploy the full OpenAM application[10] on a separate system that is reachable only from internal systems. Do not include the full OpenAM server in the load-balanced pool of OpenAM servers serving applications.
Leave
ssoadm.jspdisabled in production. (Advanced property:ssoadm.disabled=true)If possible in your deployment, control access to OpenAM console by network address, such that administrators can only connect from well-known systems and networks.
Restrict access to URIs that you do not use, and prevent internal endpoints such as
/sessionservicefrom being reachable over the Internet.For a full list of endpoints, see the OpenAM Reference Guide Chapter on Service Endpoints.
Keep administration of access management services separate from management of the services themselves.
Create realms for your organization(s) and separate administrative users from end users. For instructions, see Configuring Realms. You must then either:
Use the
realm=query string parameter when redirecting users to OpenAM, which gives you a way to isolate the URLs used by an application.realm-nameCreate fully qualified domain name realm/DNS aliases, and use them to control access to the realms.
When customizing
config/auth/default*/Login.jsp, make sure that you do not introduce any security vulnerabilities such as cross-site scripting due to unvalidated input.Create a policy agent profile for each policy agent. See Configuring Policy Agent Profiles for instructions.
Keep communications secure by using encryption, properly configured cookies, and request and response signatures.
Protect network traffic by using HTTPS and LDAPS where possible.
When using HTTPS, use secure cookies.
Where possible, use subdomain cookies, and control subdomains in a specific DNS master.
Use cookie hijacking protection with restricted tokens, where each policy agent uses different SSO tokens for the same user. See To Protect Against CDSSO Cookie Hijacking for instructions.
When using SAML 2.0:
Sign authentication requests, authentication responses, and single logout requests.
If the other entities in your circle of trust can handle encryption, then use encryption as well.
Use your own key, not the
testkey provided with OpenAM.
You can make changes to the password and user name for the main OpenAM administrative account.
You can change the user name of the amadmin administrative account
to something more obscure, such as superroot. However, the capabilities of that alternative administrative
account would not be complete, due to some hard-coding of amadmin in the source files.
When changing the password for the main OpenAM administrative account, you must make a corresponding change
to the authentication datastore. That datastore could be OpenDJ. The steps you would take to change
the OpenAM top-level administrative password and account name are shown in the following sections.
amadmin)Login to the OpenAM console as the administrator, normally
amadmin.Under Access Control > / (Top Level Realm) > Subjects > User, select the name of the current top-level administrative user.
In the page that appears, navigate to the Password row and click Edit.
In the window that appears, enter the desired new password in the New Password and Re-Enter Password text boxes.
Click OK to implement the change. If you want to cancel, click Close or just close the window.
You'll also need to change the password for the administrator on the directory server. If you are using OpenDJ, refer to the OpenDJ Administration Guide section on Resetting Administrator Passwords. If you are using a different directory server, you will have to refer to the documentation for that server.
In the following steps, you will identify the new administrative user by assigning it to the
com.sun.identity.authentication.super.user directive. You may also need to create an
OpenAM account for the new administrative user. Don't forget to make sure that new administrative
account is configured in the corresponding directory server such as OpenDJ.
amadmin)Login to the OpenAM console as the administrator, normally
amadmin.Navigate to the page where you can set the properties for different classes. Select Configuration > Servers and Sites >
Server Name> Advanced.In the Advanced Properties window that appears, click Add.
You'll see blank entries in the end of the list of Property Names and Property Values. In the empty Property Name text box, enter
com.sun.identity.authentication.super.user.In the corresponding Property Values test box, enter appropriate values for the new administrative user in LDAP Data Interchange Format (LDIF). For example, the following entry would set up an administrative user named
superroot, in the organizational unit namedpeoplepeople, associated with the example.com domain:uid=superroot,ou=people,dc=example,dc=com.Click Save to save the changes that you've made.
If the account doesn't already exist in OpenAM or on a connected directory server, you'll need to create it. To do so, select Access Control > / (Top Level Realm) > Subject > User > New. In the New User window that appears, create the new user. Make sure to enter an appropriate password and make that user Active. The ID for that new user is the user name.
As noted earlier, you'll also need to make sure that the corresponding account on the directory server has at least CN=Directory Manager privileges. If you're using OpenDJ, refer to the chapter on Configuring Privileges & Access Control in the OpenDJ Administration Guide.
If you do change the account name of the top-level administrative account, you should be aware that the
original amadmin account is "hard-coded" in the source code of several files.
The code in these files may affect the functionality of a top-level administrative user
with a name other than amadmin.
One of the improvements that we plan to make to OpenAM is to eliminate these instances of hard-coding. Until we make such improvements, the amadmin user would retain privileges related to the LoginState and some IDM-related classes.