Configuring an Identity Server
33
n
ov
do
cx (e
n)
16
Ap
ril 20
10
1.4.2 Authentication Contracts
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
.
1.4.3 Forcing 128-Bit Encryption
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.
1
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
2
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.
Summary of Contents for ACCESS MANAGER 3.1 SP2 - README 2010
Page 4: ...4 Novell Access Manager 3 1 SP2 Identity Server Guide novdocx en 16 April 2010...
Page 12: ...12 Novell Access Manager 3 1 SP2 Identity Server Guide novdocx en 16 April 2010...
Page 158: ...158 Novell Access Manager 3 1 SP2 Identity Server Guide novdocx en 16 April 2010...
Page 172: ...172 Novell Access Manager 3 1 SP2 Identity Server Guide novdocx en 16 April 2010...
Page 182: ...182 Novell Access Manager 3 1 SP2 Identity Server Guide novdocx en 16 April 2010...
Page 290: ...290 Novell Access Manager 3 1 SP2 Identity Server Guide novdocx en 16 April 2010...
Page 362: ...362 Novell Access Manager 3 1 SP2 Identity Server Guide novdocx en 16 April 2010...
Page 374: ...374 Novell Access Manager 3 1 SP2 Identity Server Guide novdocx en 16 April 2010...