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 NetIQ Access Manager 3.2 SP3 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 Response protocol binding option in Section 7.8, Configuring an Authentication Request for an Identity Provider.
For more information about how to setup federation, see Setting Up Federation
in NetIQ Access Manager 3.2 SP3 Setup Guide.
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 Identity Servers > Servers > Edit > Local > Contracts.
All client communication with the Identity Server currently uses 128-bit encryption. If the browser is unable to support 128 bit encryption, the user is not allowed to authenticate. The encryption level supported can be modified by adding or removing the ciphers listed in the server.xml file.
At a command prompt, change to the Tomcat configuration directory:
Linux: /opt/novell/nam/idp/conf
Windows Server 2008: \Program Files (x86)\Novell\Tomcat\conf
To edit the server.xml entries, search for the cipher attribute in the <Connector> element and then modify the list of ciphers based on your needs. For example, a sample configuration to enable 128-bit encryption will be as follows:
ciphers="SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_RC4_128_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:
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
For a complete list of supported cipher suites and their requirements, see The SunJSSE Provider.
To activate the cipher list, restart Tomcat.
Linux: Enter one of the following commands:
/etc/init.d/novell-idp restart
rcnovell-idp restart
Windows: Enter the following commands:
net stop Tomcat7
net start Tomcat7
(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 NetIQ Access Manager 3.2 SP3 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: /opt/novell/nam/idp/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 one of the following commands:
/etc/init.d/novell-idp restart
rcnovell-idp restart
Windows: Enter the following commands:
net stop Tomcat7
net start Tomcat7
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: /opt/novell/nam/idp/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-idp restart
rcnovell-idp restart
Windows: Enter the following commands:
net stop Tomcat7
net start Tomcat7
The following algorithms for encryption method are supported:
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/><md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/><md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/><md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep"/><md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
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: /opt/novell/nam/idp/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 one of the following commands:
/etc/init.d/novell-idp restart
rcnovell-idp restart
Windows: Enter the following commands:
net stop Tomcat7
net start Tomcat7
From Access Manager 3.2 onwards, you can configure the Identity Server to sign SAML 2.0 post messages for one or multiple trust providers.
To enable the signing of post messages for specific trust providers:
Open the nidpconfig.properties file located in /opt/novell/nam/idp/webapps/nidp/WEB-INF/classes.
Modify the following:
IS_SAML2_POST_SIGN_RESPONSE: This is a global option. Specify true to enable the Identity Provider to send signed saml2 post responses to all its trusted providers.
NOTE:Configuring IS_SAML2_POST_SIGN_RESPONSE is same configuring the SignPost in web.xml. However, configuring the nidpconfig.properties is recommended because it provides more options. These options can be combined with IS_SAML2_POST_SIGN_RESPONSE to avoid Access Manager restarts.
SAML2_POST_SIGN_RESPONSE_TRUSTEDPROVIDERS: Specify one or more trusted provider's ID. The Identity Provider will send signed SAML2 post responses to these trusted providers only.
To avoid the assertion sign validation, perform the following procedure at service provider:
Open nidpconfig.properties file located in the following path:
Linux: /opt/novell/nam/idp/webapps/nidp/WEB-INF/classes/
Windows: C:\Program Files (x86)\Novell\Tomcat\webapps\nidp\WEB-INF\classes
Add the following flag in file:
SAML2_AVOID_SIGN_AND_VALIDATE_ASSERTION_TRUSTEDPROVIDERS = entityID of the Identity Server,entityID2 of the Identity Server.
Save the configuration.
Restart the service provider. For restarting, see Step 4.
When the SAML 2.0 post response is signed and assertion is not signed, then the service provider will accept the response instead of displaying an error.
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: