This section includes the following topics:
Section 2.2.6, Third-Party Authentication and Single Sign-On
Section 2.2.7, Encryption of Sensitive User Application Data
Section 2.2.9, Modifying the Trustee Rights for User Preferences
Section 2.2.10, Modifying the Trustee Rights for a Provisioning Request Definition
Section 2.2.11, Disabling the JMX Management Console on JBOSS
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.
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:
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.
Copy the keystore file jboss.jks to your JBoss User Application directory, for example:
cp jboss.jks ~/jboss-4.2.0.GA/WAR/conf
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.
In IDMProv.war, find the web.xml file and open it in a text editor.
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>
Save the file and the archive, then restart JBoss.
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.
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.
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.
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:
<property> <key>com.novell.xss.blacklist.detailportlet</key> <value>...</value> </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.
<property> <key>com.novell.xss.blacklist.workflow</key> <value>...</value> </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.
To allow user preferences to be saved, the administrator must ensure that the permissions on the srvprvUserPrefs and srvprvQueryList attributes are set so that the user is able to write to these attributes. The necessary rights should be set for [This] at the tree root level, since [This] is a special alias to the object itself, causing only the user to have rights to modify its own preferences. To set the proper permissions, the administrator needs to modify the trustees for these attributes in iManager, as shown below:
To view the details and comments associated with a task in thesection of the Work Dashboard tab, the Domain Administrator or Delegated Administrator must have the proper rights to the provisioning request definition. In particular, the user must have the nrfAccessMgrTaskAddressee right to the provisioning request definition, with write access enabled. To set the proper permissions, the administrator needs to modify the trustees for the provisioning request definition, as described below:
Log into iManager as an administrator.
Selectfrom the left-navigation menu.
Browse to the provisioning request definition.
If necessary, clickto add the user.
Click on thelink.
Notice that nrfAccessMgrTaskAddressee is not listed with the write permission checked, which means that the user does not have the proper rights for the provisioning request definitiion.
Check the check box for.
Check thecheckbox for .
The results from a Nessus scan show that the JBoss product installer does not secure the JMX management console by default. This creates a potential security hole. To solve this problem, you need to disable the JMX console by following your JBoss documentation.