You can secure your federation relationships in numerous ways. The methods available are defined within federation protocols themselves. The method you want to use must be agreed upon by both members of a federation relationship. Specifically, this agreement is required between the identity provider (most often Access Manager’s role) and the service provider (for example, a SaaS service).
The most commonly used means of security includes using HTTPS for communication between parties secured by well-known CA certificates. For information about how to enable HTTPS in Access Manager Identity Server, see Section 7.1.3, Enabling SSL between Identity Server and a Service Provider.
Another way for SAML is the signing and/or encryption of assertions. For more information, see Section 3.5.2, Configuring the Encryption Method for the SAML Assertion. SAML also has options for communicating the assertion data between parties known as protocol bindings. Protocol bindings include Post and Artifact. The Post binding is currently simplest and most popular among SaaS vendors and is typically secured using HTTPS, assertion signing, and encryption. The Artifact binding is considered more secure, but its level of security is not always required for a federation relationship.
Post method versus exchange artifacts: When you set up a 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 SAML 2.0 Authentication Response
in the NetIQ Access Manager 4.3 Administration Guide.
NOTE:To use exchange artifact, the service provider needs to establish a direct communication channel with the identity provider.
Additional SAML protocol options may also need to be configured and matched between the identity provider and service provider. Common options are covered later in this section.
Go to Identity Servers > Servers > Edit > SAML 2.0 > Service Provider > Options and set up the following options:
SAML2 SIGN METHODDIGEST SHA256: Select true. Assertions will use the SHA 256 algorithm as a hashing algorithm for the service provider.
SAML2 POST SIGN RESPONSE TRUSTEDPROVIDERS: Select true. The identity provider will sign the entire SAML 2.0 response for the service provider.
SAML2 AVOID AUDIENCE RESTRICTION: Select true to avoid sending the audience restriction information with assertion to this service provider.
IS SAML2 POST SIGN RESPONSE: Select 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 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.
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/
Windows Server 2012: \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"/>