2.2 Security

This section includes the following topics:

2.2.1 Security Overview

Moving from pre-production to production usually involves hardening the security aspects of the system. In sandbox testing, you might use regular HTTP to connect the User Application driver to the application server, or you might use a self-signed certificate (as a temporary measure) for driver/app-server communication. In production, on the other hand, you probably use secure connections, with server authentication based on your company’s Verisign* (or other trusted provider) certificate.

It is typical for X.509 certificates to be used in a variety of places in the Identity Manager User Application environment, as shown in the following diagram.

Figure 2-2 Identity Manager User Application Environment

Illustration

All communication between the User Application and the Identity Vault is secure, using Transport Layer Security, by default. The installation of the Identity Vault (eDirectory) certificate into the JBoss application server keystore is done automatically at install time. Unless you specify otherwise, the User Application installer places a copy of the eDirectory certificate in the JRE’s default cacerts store. The installation of the certificate into the WebSphere application server keystore must be done manually using WebSphere tools.

The server certificate needs to be in several places, if communications are to be secure, as shown in the diagram. Different setup steps might be needed depending on whether you intend to use a self-signed certificate in the various places in the diagram shown with a JBoss cert box, or you intend to use a certificate issued by a trusted certificate authority (CA) such as Verisign.

2.2.2 Self-Signed Certificates

If you are using a certificate from a well-known trusted issuer (for example, Verisign), no special configuration steps should be necessary. But if you intend to create and use a self-signed certificate, use the following steps:

  1. Create a keystore with a self-signed certificate, using command line syntax similar to the following. Change the dname value to match your web site and organization; change other values as appropriate. 

    keytool -genkey -alias IDM -keyalg RSA -storepass changeit -keystore jboss.jks -dname "cn=www.novell.com,o=Novell,s=MA,c=US" -keypass changeit

    Notice that you are creating the file jboss.jks as well as the certificate.

  2. Copy the keystore file jboss.jks to your JBoss User Application directory, for example: 

    cp jboss.jks ~/jboss-4.2.0.GA/WAR/conf

2.2.3 Enabling SSL

The User Application uses HTML forms for authentication. As a result, user credentials are exposed during login. We strongly recommend that you enable SSL to protect sensitive information.

Table 2-1 lists references to directions on implementing SSL.

Table 2-1 Directions on Implementing SSL

For Directions On

See

Configuring Access Manager to use SSL

Novell Access Manager 3.0 SP1 Setup Guide if you are using Access Manager to log in to the User Application.

Configuring the application server to use SSL

Documentation provided by the application server manufacturer. Configure the application server to user SSL before you configure the IDM User Application to use SSL.

Configuring the IDM User Application (as client) to use SSL to connect to the Identity Vault

Roles Based Provisioning Module Installation Guide for information on setting the following User Application configuration parameters at installation: Secure Admin Connection and Secure User Connection. These parameters can also be edited with the configupdate utility.

2.2.4 Turning on SOAP Security

  1. In IDMProv.war, find the web.xml file and open it in a text editor.

  2. At the bottom of the file, uncomment the following section:

    <security-constraint>
        <web-resource-collection>
                <web-resource-name>IDMProv</web-resource-name>
                <url-pattern>/*</url-pattern>
                <http-method>POST</http-method>
                <http-method>GET</http-method>
                <description>IDM Provisioning Edition</description>
                </web-resource-collection>
        <user-data-constraint>
                <transport-guarantee>CONFIDENTIAL</transport guarantee>
        </user-data-constraint>
</security-constraint>

  3. Save the file and the archive, then restart JBoss.

2.2.5 Mutual Authentication

The Identity Manager User Application does not support client certificate-based authentication out of the box. That functionality can be obtained, however, by using Novell® Access Manager. See your Novell representative for more information. See also Section 2.2.6, Third-Party Authentication and Single Sign-On.

2.2.6 Third-Party Authentication and Single Sign-On

The Identity Manager User Application supports single sign-on through Access Manager using any third-party authentication service that can log into Access Manager. This capability enables using a non-password-based technology to log into the User Application through Access Manager. An example is logging in through a user (client) certificate, for example from a smart card.

Access Manager maps the user to a DN in the IDM Identity Vault. When a user logs into the User Application through Access Manager, Access Manager can inject a SAML assertion (with the user’s DN as the identifier) into an HTTP header and forwards the request to the User Application. The User Application uses the SAML assertion to establish the LDAP connection with the Identity Vault. For information on configuring Access Manager to support this capability, refer to the Access Manager documentation.

To secure the channels that carry requests, place the channels behind a firewall or on SSL connections. Table 2-1 lists references to directions on setting up SSL in your User Application environment.

Accessory portlets that allow single sign-on authentication based on passwords currently do not support single sign-on when SAML assertions are used for User Application authentication.

2.2.7 Encryption of Sensitive User Application Data

Any sensitive information associated with the User Application that is stored persistently is encrypted by using the symmetric algorithm AES-128. The master key itself is protected by password-based cryptography using PBEWithSHA1AndDESede. The password is never persisted or stored out of memory.

Information that is encrypted includes (but is not limited to):

  • LDAP administrator user password

  • LDAP guest user password

  • DSS trusted CA keystore password

  • DSS signature key keystore password

  • DSS signature key entry password

  • Novell Audit signature key

However, in a cluster environment, if session failover is enabled, some sensitive data (for example, a login-password for portlet single sign-on) in the user session can be transferred on the network during session replication. This can expose sensitive data to network sniffers. To protect this sensitive data, do one of the following:

  • Enable encryption for JGroups. For information about enabling JGroups encryption, see JGroups Encrypt.

  • Make sure that the cluster is behind a firewall.