You can increase security of Identity Server by considering the following topics:
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 Configuring a SAML 2.0 Authentication Request and Configuring a Liberty Authentication Request.
For more information about how to setup federation, see Section 5.2.1, Configuring Federation.
By default, 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.
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 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 Administration Console and click Identity Servers > Servers > Edit > Local > Contracts.
All client communication with Identity Server currently uses 128-bit encryption. If the browser is unable to support 128 bit encryption, the user is not allowed to authenticate. You can modify the supported encryption level 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
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:
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
(Conditional) If you have multiple Identity Servers in your cluster configuration, repeat these steps on each Identity Server.
Preventing Automatically Changing the Session ID
Click Devices > Identity Servers > Edit > Options > New.
Set the RENAME SESSION ID property to false.
Restart Tomcat on each Identity Server in the cluster.
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. To use PKCS 2.0 (RSA-OAEP) for encryption, see TID.
Open the web.xml file.
Linux: /opt/novell/nam/idp/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
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, Identity Server does not require the signing post messages. However, if you want this extra layer of security, you can configure 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/
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
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:
Enable the following properties in the Administration Console. For information about how to set properties in the Administration Console, see Configuring Identity Server Global Options and Defining Options for SAML 2.0.
IS SAML2 POST SIGN RESPONSE: Specify true to enable the identity provider to send signed SAML 2.0 post responses to all its trusted providers.
NOTE:Configuring IS SAML2 POST SIGN RESPONSE is same as configuring the SignPost in web.xml. However, configuring it through the Administration Console is recommended because it provides more options. You can combine these options with IS SAML2 POST SIGN RESPONSE to avoid Access Manager restarts.
SAML2 POST SIGN RESPONSE TRUSTEDPROVIDERS: Specify one or more trusted provider's entityID. Set the value as true to verify the signed SAML 2.0 post responses.
You can enable the SAML2 AVOID SIGN AND VALIDATE ASSERTION TRUSTEDPROVIDERS option on both identity provider and service provider.
If this flag is set on the identity provider, then the complete POST message (excluding the assertion) is signed.
If this option is set on the service provider, then the signature of the POST message is verified but the assertion signature is not verified. If this option is not set on the service provider and an identity provider sends an assertion where only the assertion is signed, the service provider cannot validate it.
To avoid the assertion signing or validation, perform the following procedure at identity provider/service provider.
In Administration Console, click Identity Server > Edit > SAML 2.0 > Service Provider or Identity Provider > Options > New.
Select SAML2 AVOID SIGN AND VALIDATE ASSERTION TRUSTEDPROVIDERS and specify the value in this format: entityID of the identity provider, entityID2 of the service provider.
NOTE:The entityID of the identity provider and the service provider are comma-separated values.
For example, to enable this flag on the identity provider use the following format: https://www.idp.com:8443/nidp/saml/metadata
For example, to enable this flag on the service provider use the following format: https://www.sp.com:8443/nidp/saml/metadata
Save the configuration.
Restart Identity Server. For restarting, see Step 4.
When this flag is set in the service provider, the SAML 2.0 POST response is signed and assertion is not signed. The service provider will accept the response instead of returning an error.
Identity Server has a couple of pages that authenticated users can access and which contain information about the user and Identity Server that some security models deem sensitive. If you want to block user access to these pages, see the following sections: