By default, all Access Manager components (Identity Server, Access Gateway, SSL VPN, and J2EE Agents) trust the certificates signed by the local CA. We recommend that you configure the Identity Server to use an SSL certificate signed externally, and that you configure the trusted store of the Embedded Service Provider for each component to trust this new CA. See Assigning Certificates to Access Manager Devices
in the Novell Access Manager 3.1 SP2 Administration Console Guide.
Be aware of the following options that can increase security:
When you set up federation between an identity provider and a service provider, you can select either to exchange assertions with a post method or to exchange artifacts.
An assertion in a post method might contain the user’s password or other sensitive data, which can make it less secure than an artifact when the assertion is sent to the browser. It is possible for a virus on the browser machine to access the memory where the browser decrypts the assertion.
An artifact is a randomly generated ID, it contains no sensitive data, and only the intended receiver can use it to retrieve assertion data.
If both providers support artifacts, you should select this method because it is more secure. For more details, see the option in Section 7.8, Configuring an Authentication Request for an Identity Provider.
By default, the Administration Console allows you to select from the following contracts and options when specifying whether a resource requires an authentication contract:
None: Allows public access to the resource and does not require authentication contract.
Name/Password - Basic: Requires that the user enter a name and password that matches an entry in an LDAP user store. The credentials do not need to be sent over a secure port. This uses the unprotected BasicClass, which is not recommended for a production environment.
Name/Password - Form: Requires that the user enter a name and password that matches an entry in an LDAP user store. The credentials do not need to be sent over a secure port, although they can be if the user is configured for HTTPS. This contract uses the unprotected PasswordClass, which is not recommended for a production environment.
Secure Name/Password - Basic: Requires that the user enter the name and password from a secure (SSL) connection. This uses the ProtectedBasicClass, which is recommended for a production environment. If your Web servers are using basic authentication, this contract provides the credentials for this type of authentication.
Secure Name/Password - Form: Requires that the user enter the name and password from a secure (SSL) connection. This uses the ProtectedPasswordClass, which is recommended for a production environment.
Any Contract: Allows the user to use any contract defined for the Identity Server configuration.
If you have set up the Access Manager to require SSL connections among all of its components, you should delete the Name/Password - Form and the Name/Password - Basic contracts. This removes them from the list of available contracts when configuring protected resources and prevents them from being assigned as the contract for a protected resource. If these contracts are assigned, the user’s password can be sent across the wire in clear text format. At some future date, if your system needs this type of contract, you can re-create it from the method. To delete these contracts, go to the Administration Console and click > > > > .
You can force all client communication with the Identity Server to use 128-bit encryption by modifying the server.xml file used by Tomcat. If the browser is unable to supported the encryption level specified in this file, the user is not allowed to authenticate.
At a command prompt, change to the Tomcat configuration directory:
Linux: /var/opt/novell/tomcat5/conf
Windows Server 2003: \Program Files\Novell\Tomcat\conf
Windows Server 2008: \Program Files (x86)\Novell\Tomcat\conf
To the server.xml file, add the cipher suites you want to support. For 128-bit encryption, add the following line:
ciphers="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA"
This is a comma-separated list of the JSSE names for the TLS cipher suites.
IMPORTANT:If you enter a cipher name incorrectly, Tomcat reverts to the default values, which allow the weak ciphers to be used.
If you want to allow the SSL cipher suites, the following JSSE names can be added to the list:
For a complete list of supported cipher suites and their requirements, see The SunJSSE Provider.
To activate the cipher list, restart Tomcat.
Linux: Enter the following command:
/etc/init.d/novell-tomcat5 restart
Windows: Enter the following commands:
net stop Tomcat5
net start Tomcat5
(Conditional) If you have multiple Identity Servers in your cluster configuration, repeat these steps on each Identity Server.
An attacker can spoof a non-secure browser into sending a JSESSION cookie that contains a valid user session. To stop this from happening, you need to first configure the Identity Server to use SSL. For configuration information, see Configuring Secure Communication on the Identity Server
in the Novell Access Manager 3.1 SP2 Setup Guide.
After you have configured the Identity Server to use SSL, you need to configure Tomcat to secure the cookie.
On the Identity Server, log in as the administrator.
Change to the Tomcat configuration directory:
Linux: /var/opt/novell/tomcat5/conf
Windows Server 2003: \Program Files\Novell\Tomcat\conf
Windows Server 2008: \Program Files (x86)\Novell\Tomcat\conf
Create a context.xml file with the following content:
<Context useHttpOnly="true"> </Context>
Save the file, then restart Tomcat:
Linux: Enter the following command:
/etc/init.d/novell-tomcat5 restart
Windows: Enter the following commands:
net stop Tomcat5
net start Tomcat5
By default, AES128 (Advanced Standard Encryption, 128-bit) is used to encrypt SAML assertions. If you require a different encryption method, such as TDES (Triple Data Encryption Algorithm) or AES256 (Advanced Standard Encryption, 256-bit), you can modify the Tomcat web.xml file and specify your required method.
Open the web.xml file.
Linux: /var/opt/novell/tomcat5/webapps/nidp/WEB-INF/
Windows Server 2003: \Program Files\Novell\Tomcat\webapps\nidp\WEB-INF/
Windows Server 2008: \Program Files (x86)\Novell\Tomcat\webapps\nidp\WEB-INF/
Add the following lines to the file:
<context-param>
<param-name>EncryptionMethod</param-name>
<param-value>TDES</param-value>
</context-param>
You can set the <param-value> element to TDES, AES128, or AES256. Because AES128 is the default, specifying this value in the web.xml file does not change any behavior.
Save the file and copy it to each Identity Server in the cluster.
Restart Tomcat on each Identity Server in the cluster.
Linux: Enter the following command:
/etc/init.d/novell-tomcat5 restart
Windows: Enter the following commands:
net stop Tomcat5
net start Tomcat5
In conformance with the SAML 2.0 specification, the Identity Server does not require the signing post messages. However, if you want this extra layer of security, you can configure the Identity Server to sign SAML 2.0 post messages. This is a global option, and when enabled, all SAML 2.0 service providers sign post messages.
To enable the signing of post messages:
Open the web.xml file.
Linux: /var/opt/novell/tomcat5/webapps/nidp/WEB-INF/
Windows Server 2003: \Program Files\Novell\Tomcat\webapps\nidp\WEB-INF/
Windows Server 2008: \Program Files (x86)\Novell\Tomcat\webapps\nidp\WEB-INF/
Add the following lines to the file:
<context-param>
<param-name>SignPost</param-name>
<param-value>true</param-value>
</context-param>
Save the file and copy it to each Identity Server in the cluster.
Restart Tomcat on each Identity Server in the cluster.
Linux: Enter the following command:
/etc/init.d/novell-tomcat5 restart
Windows: Enter the following commands:
net stop Tomcat5
net start Tomcat5
The Identity Server has a couple of pages that authenticated users can access and which contain information about the user and the Identity Server that some security models deem sensitive. If you want to block user access to these pages, see the following sections: