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


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 or the WebLogic keystore must be done manually using your vendor’s 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


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:

                    <description>IDM Provisioning Edition</description>
                    <transport-guarantee>CONFIDENTIAL</transport guarantee>
  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.

2.2.8 Preventing XSS Attacks

The User Application supports the concept of XSS (Cross-Site Scripting) blacklists to allow you to prevent scripting attacks. The XSS blacklists prevent XSS injection in the free text input fields within the Detail portlet, approval flow, and role assignments pages within the application.

The User Application provides default values for two blacklists, one for the Detail Portlet, and one for the workflow system (which handles the approval flow and role assignments pages). However, you can customize the blacklists to suit the requirements of your environment.

To customize the either of the blacklists, you need to enter the words or characters you want to block in the sys-configuration-xmldata.xml file. In JBoss, you can find this file in the <jboss_home>/server/<IDM>/conf folder. Open the file with a UTF-8 friendly editor.

To modify the blacklist for the Detail portlet, open <jboss_home>/server/<IDM>/conf/sys-configuration-xmldata.xml in a UTF-8 editor, and find the com.novell.xss.blacklist.detailportlet property:


The text node of <value> is the blacklist for Detail portlet. The blocked words are separated by comma (for example, blocked_word1,blocked_word2,...). The default setting is:


This means that double quote and < are disallowed.

To modify the blacklist for the approval flow and role assignments pages, locate the com.novell.xss.blacklist.workflow property.


The syntax is the same. The default value is:


which means that < is disallowed.

If you decide to customize the blacklists, be careful not to remove the default values. If you remove these values, you will make the lists less restricted, and therefore increase the risk of XSS attacks.