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 service provider for each component to trust this new CA. See Section 25.0, Assigning Certificates to Access Manager Devices.
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 artifact is a randomly generated ID, it contains no sensitive data, and only the intended receiver can use it to retrieve assertion data. Assertions might contain the user’s password or other sensitive data, which can make them 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. 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 10.1, Configuring Authentication for a Trusted 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. This 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 goes 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 > > > > .
If you use X.509 contracts for authentication, be aware that some browsers, such as Internet Explorer, keep the SSL session active until the user closes the browser. If the user logs in with the certificate on a smart card, then removes the card and logs out but does not close the browser, the SSL session is still active. Another user can then use the existing session.
To prevent this from happening, do one of the following:
You can write a JavaScript that automatically closes the browser. See “Security Vulnerability: Logged out users authenticated with X509 certificates can log back in without resending personal certificates using the same browser window”.
You can edit the tomcat4.conf file on the Identity Server.
To edit the tomcat4.conf file:
On the Identity Server, change to the /var/opt/novell/tomcat4/conf directory.
Open the tomcat4.conf file.
Add the following line to the file:
JAVA_OPTS="${JAVA_OPTS} -Dcom.novell.nidp.x509.forceRestartMsg=true"
This allows the Identity Server to send a message to the users informing them that they must close the browser and start a new session before they can log in again.
Save the file.
Restart Tomcat by entering the following command:
/etc/init.d/novell-tomcat4 restart