Chapter 14. OpenAM

OpenAM is an open source access management, entitlements and federation server platform. It is a successor of OpenSSO, the access management and federation server platform, whose integration was available in Red Hat JBoss Portal 5. As the development of OpenSSO has been discontinued, the OpenSSO integration has been replaced with OpenAM integration in Red Hat JBoss Portal 6.

14.1. Downloading OpenAM

OpenAM must be obtained from Forgerock. Only the 9.5 and 10.0 versions of OpenAM are fully tested and supported with the portal. Integration with other versions may be functional, but has not been fully tested and is therefore not supported.
The procedures in this section assume that OpenAM is obtained in the form of a ZIP distribution. Once downloaded, extract the contents of the ZIP package into a location of your choice. This location will be referred to as OPENAM_HOME in the following text.

14.2. OpenAM Workflow

When the OpenAM integration is configured and a user clicks the Sign in link on a portal page, they are redirected to the OpenAM login screen, where they provide login credentials. Authentication on the OpenAM server side is performed by the portal SSO Authentication Plug-in. The plug-in sends a REST request to the portal, obtains a response, and authenticates the user on the OpenAM side based on the response.
After successful authentication with OpenAM, an OpenAM authentication ticket is stored in the iPlanetDirectoryPro cookie in the client browser and the user is redirected back to the portal page. When the portal page is requested, the InitiateLoginFilter interceptor delegates validation of the OpenAM ticket to the OpenSSOAgent component. The OpenSSOAgent then uses the OpenAM REST API to perform back channel validation of the ticket with the OpenAM server. After successful validation, user identity is established and the user is logged into the portal.
When logout is requested by clicking the Sign out button on a portal page, the OpenSSOLogoutFilter interceptor performs logout on both the portal and OpenAM servers.
The OpenAM login and logout workflow is similar to the CAS authentication workflow.

14.3. OpenAM Server

14.3.1. Setting up OpenAM Server

This section contains procedures that need to be followed to set up an OpenAM server for authentication against the portal. The authentication set up by these procedures is ensured by the portal SSO Authentication Plug-in. The plug-in will be installed in OpenAM and configured to perform authentication against the portal using a REST callback.

Procedure 14.1. Setting up OpenAM Server

To setup OpenAM server, follow these steps.
  1. Deploy the OpenAM server.
  2. Add the authentication plugin.
  3. Configure a realm in OpenAM user interface.

Note

Using the REST callback as presented in this section is not mandatory. You can achieve authentication on the OpenAM side by any other means according to your preference.

14.3.2. Deploying the OpenAM Server

Procedure 14.2. Deploying the OpenAM Server

  1. Obtain a copy of Tomcat 7 and extract it into a suitable location. This location will be referred to as TOMCAT_HOME further in the text.
  2. Deploy OpenAM to Tomcat by copying the OPENAM_HOME/opensso/deployable-war/opensso.war archive to the TOMCAT_HOME/webapps/ directory.

    Note

    The name of the WAR file is still opensso.war, even if it contains OpenAM, which is the successor of OpenSSO. The context of the OpenAM web application has also kept the name /opensso.
  3. Change the default Tomcat port to avoid conflict with the default portal port. For the purpose of this example, change it to 8888 by editing the TOMCAT_HOME/conf/server.xml configuration file and replacing the 8080 port number with 8888.
  4. If the portal is running on the same machine as Tomcat, other Tomcat port numbers also need to be changed to avoid conflicts. These port numbers can be changed to any unassigned port numbers available on the machine. For example, change the admin port from 8005 to 8805 and the AJP port from 8009 to 8809 if the latter are not assigned.

14.3.3. Adding the Authentication Plugin

Procedure 14.3. Adding the Authentication Plug-in

  1. Copy the contents of the JPP_DIST/gatein-sso/opensso/plug-in/ directory to TOMCAT_HOME/webapps/opensso/. This will add:
    • the AuthenticationPlugin.xml file to the TOMCAT_HOME/webapps/opensso/config/auth/default/ directory. The file contains the following configuration:

      Example 14.1. AuthenticationPlugin.xml Example Content

      
      <?xml version='1.0' encoding="UTF-8"?>
      <!DOCTYPE ModuleProperties PUBLIC "=//iPlanet//Authentication Module Properties XML Interface 1.0 DTD//EN" "jar://com/sun/identity/authentication/Auth_Module_Properties.dtd">
       
      <ModuleProperties moduleName="AuthenticationPlugin" version="1.0">
        <Callbacks length="2" order="1" timeout="60" header="GateIn OpenAM Login">
          <NameCallback>
            <Prompt>
              Username
            </Prompt>
          </NameCallback>
          <PasswordCallback echoPassword="false">
            <Prompt>
              Password
            </Prompt>
          </PasswordCallback>
        </Callbacks>
      </ModuleProperties>
      
    • the sso-opensso-plugin-<VERSION>.jar, sso-common-plugin-<VERSION>.jar and commons-httpclient-<VERSION>.jar archives to the TOMCAT_HOME/webapps/opensso/WEB-INF/lib directory.
    • the gatein.properties file to the TOMCAT_HOME/webapps/opensso/WEB-INF/classes/ directory. If necessary, change the values specified in this file to match the configuration of the portal instance. The values are used by the authentication plug-in to establish the REST connection to the portal.
  2. Start Tomcat and verify that the OpenAM user interface at http://localhost:8888/opensso is accessible.

14.3.4. Configuring a Realm in OpenAM User Interface

Procedure 14.4. Configuring a Realm in OpenAM User Interface

  1. Create the default configuration.
  2. Login as amadmin and navigate to ConfigurationAuthentication.
  3. Select the Core link, add a new value containing the org.gatein.sso.opensso.plugin.AuthenticationPlugin class name and click Save. This step is important for the portal SSO Authentication Plug-in to be available among other OpenAM authentication modules.
  4. Go to the Access control tab and create a new realm called gatein.
  5. Go to the gatein realm and click the Authentication tab. In the Authentication chaining section at the bottom of the tab, click ldapService. Here, change the selection from Datastore, which is the default module in the authentication chain, to AuthenticationPlugin. This ensures that authentication of the gatein realm will be performed using the portal REST service instead of the OpenAM LDAP server.
  6. Still on the Authentication tab of the gatein realm, click the All Core Settings button. When the settings are displayed, change the UserProfile value from Required to Dynamic. This is needed because portal users are not initially present in the OpenAM LDAP server data store. The Dynamic value ensures that all users are automatically added to the data store after their first successful authentication.
  7. Go to Access controlTop level realmPrivilegesAll authenticated users and mark the following check boxes:
    • Read and write access only for policy properties
    • Read and write access to all realm and policy properties
    Adding these privileges allows REST access to the OpenAM server.
  8. Repeat the previous step to increase the privileges also for the gatein realm.

14.4. Configuring the Platform as an OpenAM Client

On the portal server, you need to ensure proper configuration of single sign-on properties in the JPP_HOME/standalone/configuration/gatein/configuration.properties file. Locate the SSO section in this file and change/add properties in the section as follows:
# SSO
gatein.sso.enabled=true
gatein.sso.callback.enabled=${gatein.sso.enabled}
gatein.sso.login.module.enabled=${gatein.sso.enabled}
gatein.sso.login.module.class=org.gatein.sso.agent.login.SSOLoginModule
gatein.sso.server.url=http://localhost:8888/opensso
gatein.sso.openam.realm=gatein
gatein.sso.portal.url=http://localhost:8080
gatein.sso.filter.logout.class=org.gatein.sso.agent.filter.OpenSSOLogoutFilter
gatein.sso.filter.logout.url=${gatein.sso.server.url}/UI/Logout
gatein.sso.filter.login.sso.url=${gatein.sso.server.url}/UI/Login?realm=${gatein.sso.openam.realm}&goto=${gatein.sso.portal.url}/@@portal.container.name@@/initiatessologin

Disable the new OpenAM UI

OpenAM 12.0 has a bug on the logout procedure through the new UI, called XUI which prevents the correct redirection. The workaround is to disable the newest UI (XUI) and use the classic UI.

To disable the new UI

  1. Open the OpenAM administration console and access Configuration.
  2. Select Core and uncheck the option XUI interface
Most of the properties are described for CAS integration.
Values of some properties are different with OpenAM, specifically the URLs for login/logout redirection, the logout filter class and the gatein.sso.server.url property, which points to the location of the OpenAM server. The gatein.sso.openam.realm value points to the realm created on the OpenAM server.
With all the previously described configuration, all links redirecting users to authentication pages will redirect them to the OpenAM authentication form. On the OpenAM side, users will be able to log in to the gatein realm using their portal credentials.
Screen shot of the OpenAM Login page.

Figure 14.1. OpenAM Login Page

14.5. Cross-domain with OpenAM

14.5.1. Authenticating Cross-domain with OpenAM

The configuration described in Section 14.3.1, “Setting up OpenAM Server” and Section 14.4, “Configuring the Platform as an OpenAM Client” assumes that the portal and OpenAM are deployed on the same server or in the same DNS domain.
In such an environment, OpenAM adds the iPlanetDirectoryPro cookie for the shared domain to the client browser. It stores the authentication token in the cookie and performs redirection to the OpenSSOAgent in the portal. The agent is able to read the token from the cookie and perform its validation because the portal is running in the same domain.
This is not possible when the portal server and the OpenAM server are running in different domains and cannot share cookies. OpenAM provides the CDCServlet to solve this situation. Authenticated users can send requests to this servlet and the servlet responds with an encoded SAML message containing the SSO token and other information required to authenticate. The portal agent is then able to parse and validate the message, obtain the SSO token and establish the iPlanetDirectoryPro cookie for the domain where the portal is deployed. Once the OpenAM agent on the portal side has the token, it can perform further validation of this token and finish authentication of the user.
Detailed information about the CDCServlet servlet can be found in Sun OpenSSO Enterprise Deployment Planning Guide.

14.5.2. Configuring Cross-domain Authentication

Procedure 14.5. Cross-domain Authentication Configuration

For the purpose of this example, we will assume that the OpenAM server is deployed on the opensso.mydomain.com host and the portal server on the portal.yourdomain.com host.
Configure virtual hosts to simulate this configuration on a single machine. On Linux, this can be achieved by editing the /etc/hosts file and adding records similar to the following, with the IP addresses changed accordingly:
opensso.mydomain.com 192.168.2.7
portal.yourdomain.com 10.11.12.13
  1. On the portal side, single sign-on configuration in the configuration.properties file must be specified as follows:
    # SSO
    gatein.sso.enabled=true
    gatein.sso.callback.enabled=${gatein.sso.enabled}
    gatein.sso.login.module.enabled=${gatein.sso.enabled}
    gatein.sso.login.module.class=org.gatein.sso.agent.login.SSOLoginModule
    gatein.sso.server.url=http://opensso.mydomain.com:8888/opensso
    gatein.sso.openam.realm=gatein
    gatein.sso.portal.url=http://portal.yourdomain.com:8080
    gatein.sso.filter.logout.class=org.gatein.sso.agent.filter.OpenSSOLogoutFilter
    gatein.sso.filter.logout.url=${gatein.sso.server.url}/UI/Logout
    gatein.sso.filter.login.enabled=false
    gatein.sso.filter.login.openamcdc.enabled=true
    gatein.sso.filter.login.sso.url=${gatein.sso.server.url}/cdcservlet
    
    As we need to redirect requests to the CDCServlet, the gatein.sso.filter.login.sso.url property points to the URL of the servlet. It is also necessary to use a modified version of the LoginRedirectFilter interceptor. That is why the gatein.sso.filter.login.openamcdc.enabled value is changed to true and the gatein.sso.filter.login.enabled value is now set to false.
  2. Access the OpenAM user interface at http://opensso.mydomain.com:8888/opensso and log in as amadmin.
  3. Navigate to Access Control"gatein" realmAgentsWeb.
  4. Create a new web agent through the wizard using the following properties:
    Creating this agent is required for the CDCServlet to work properly. If you have more portal servers on different hosts, you may want to create an agent for each of them. See the OpenAM Administration Guide available from http://openam.forgerock.org/doc/admin-guide/index.html for more details.