Login Configuration

Cams uses the Java Authentication and Authorization Service (JAAS) to provide user authentication services. The JAAS authentication API defines a Java version of the Pluggable Authentication Module (PAM) framework, which permits applications to remain independent from underlying authentication technologies. The PAM framework allows the use of new or updated authentication technologies without requiring modification to applications. Cams does not use the authorization features of JAAS.

This document describes how to configure Cams login modules, which are used to authenticate users and obtain their roles. See also the Login Configuration Tag Reference for more information on all the XML tags used in the login-config.xml file.

NOTE: If an existing Cams login module does not meet your needs, Programming Cams JAAS Login Modules explains how to create a new Cams login module. Source code is provided as a reference for all existing Cams login modules.

Login Configuration

Each Cams security domain must have a login configuration defined in a login-config.xml file. The login-config.xml file contains both required and optional data specific to each login module. One or more login module configurations can be specified by nesting values within one or multiple <login-config-entry name="name"> and </login-config-entry> tags, as you can see in the sample login-config.xml file.

Within the <login-config-entry> open and close tags, you specify how login modules will be used. The parameters className and flag are required for each login module entry as show in example 1. The class name specifies the fully qualified location of the Java class for the specified login module. The login modules currently supplied with Cams include:

• com.cafesoft.cams.auth.login.module.ActiveDirectoryLoginModule
• com.cafesoft.cams.auth.login.module.JdbcLoginModule
• com.cafesoft.cams.auth.login.module.LdapLoginModule
• com.cafesoft.cams.auth.login.module.SiteServerLoginModule
• com.cafesoft.cams.auth.login.module.XmlLoginModule

<login-config-entry name="http">
	<login-module-entry
		className="com.cafesoft.cams.auth.login.module.XmlLoginModule"
		flag="REQUIRED">
		<options>
			<option name="serviceId" value="cams-user-repository"/>
			<option name="debug" value="true"/>
		</options>
	</login-module-entry>
</login-config-entry>	

A <login-config-entry> can have one or more <login-module-entry>. The flag parameter determines the behavior when multiple login modules are used by specifying whether a module is required, requisite, sufficient, or optional.

• REQUIRED - Normally set when authentication by this module is a must. With this flag, any module failure results in the PAM framework returning the error to the caller after executing all other modules on the stack. For the function to be able to return success to the application, all required modules have to report success.
• REQUISITE - The module must be successfully checked in order for the authentication to be successful. If a requisite module check fails, the user is notified immediately with a message reflecting the first failed required or requisite module.
• SUFFICIENT - Used if the module succeeds the PAM framework, then returns success to the application immediately without trying any other modules. For failure cases, the sufficient modules are treated as optional.
• OPTIONAL - Used when the user is allowed access, even if that module has failed. With this flag, the PAM framework ignores the module failure and continues processing the next module in sequence.

Specifying more than one <login-module-entry> for a single <login-config-entry> configuration is also known as stacking. The interaction between flags when stacking can be complicated. It is recommended that you keep these configurations as simple as possible. In most cases, you'll specify a single login module with flag value set to REQUIRED.

The optional values are specific to each login module and are explained in the sections below. All options tags require name and value parameters. For example, all Cams login modules include a debug option to toggle on/off debug. The tag is <option name="debug" value="true"/> with the value either true or false.

Login Modules

The login modules included with Cams are:

• Active Directory Login Module - for use with Microsoft Active Directory
• JDBC Login Module - for use with SQL databases that have JDBC drivers
• LDAP Login Module - for use with most LDAPv3 compliant directories
• Site Server Login Module - for use with the Microsoft Site Server LDAP server
• XML Login Module - for use with the Cams XML user directory

Active Directory Login Module

You use this login module to access user data that is stored in the Microsoft Active Directory server. Active Directory, like most directory servers, can be configured to support virtually any schema. The Cams Active Directory login module provides support for the default Active Directory schema as shown in example 2.

The Active Directory login module expects to find a schema as shown in example 2, with the user values stored in specific attributes. The steps the Active Directory login module must successfully perform are:

1. Authentication - The Active Directory user principal names (UPN) such as name@company.com is required for authentication. The Active Directory Login Module attempts to bind to Active Directory using the UPN and the password. If successful, the users roles are then queried and saved.
2. Role Assignment - Once successful authentication is performed, the Cams Active Directory login module then assigns the user roles based upon the role attribute supplied during configuration. Active Directory often use the group memberOf attribute, which specifies the groups to which the user belongs. The individual group names are fully qualified distinguished names and must be exploded to obtain the common name, which is expected to be found in the left most component (e.g., the group name for distinguished name cn=mygroup,cn=users,dc=mycompany,dc=com would be mygroup).

Example 3 shows the sample entry for the Active Directory login module.

<login-module-entry
  className="com.cafesoft.cams.auth.login.module.ActiveDirectoryLoginModule"
  flag="REQUIRED">
 <options>
  <option name="debug"    value="false"/>
  <option name="host"     value="host.company.com"/>
  <option name="port"     value="389"/>
  <option name="baseDN"   value="cn=Users,dc=company,dc=com"/>
  <option name="scope"    value="ONE"/>
  <option name="filter"   value="(&amp;(objectclass=user)(userPrincipalName={username}))"/>
  <option name="roleAttr" value="memberOf"/> 
 </options>
</login-module-entry>

The required Active Directory login module options values are:

• host - The DNS host name or IP address of the Active Directory server.
• port - The Active Directory server connection port (389 by default). Note that the Active Directory login module may also connect to the Global Catalog (port 3268 by default).
• connectTimeout - (Optional) The number of milliseconds to wait for a connection to the Active Directory before timing out.
• emptyPassword - (Optional) Allow use of empty passwords (false by default). Set this value to true to allow use of empty passwords when Active Directory is configured for and anonymous binds are required.
• defaultRoles - (Optional) A list of one or more default roles separated by a comma to be added to the user session.
• domain - (Optional) The Active Directory domain to use. If this value is present then append "@" and the value of domain to the username before attempting to bind.
• baseDN - The base distinguished name for the user search. Always cn=Users,dc=company,dc=com for Active Directory's default schema, where the values company and com correspond to the domain configured for the particular directory.
• scope - Specifies the search scope to use. Valid values are BASE (search is done only at the base dn tree node), ONE (search is done only at the first child tree node of the base dn), and SUB (search is done at the base dn node and all child nodes). This should be set to ONE for most Active Directory sites.
• filter - The filter to use to search for a user's roles. The UPN entered by the the user at login will be substituted for the value "{username}".
• roleAttr - The name of the attribute that contains the role distinguished names. Thought groups and roles are not the same, many Active Directory sites use the memberOf group attribute for this purpose.

JDBC Login Module

You use this login module to access user repository information that is stored in SQL databases such as Oracle, DB2, Microsoft SQL, MySQL, Sybase, and virtually any other database with a JDBC driver. The sample configuration uses the JDBC to ODBC bridge that ships with the JDK to access a Windows datasource (DSN) named SampleJdbcLogin. You can configure the sample Microsoft Access database with the SampleJdbcModule DSN to test the JDBC login module. Example 4 shows the sample entry for the JDBC login module.

<login-module-entry
  className="com.cafesoft.cams.auth.login.module.JdbcLoginModule"
  flag="REQUIRED">
 <options>
  <option name="debug" value="false"/>
  <option name="jdbcDriver" value="sun.jdbc.odbc.JdbcOdbcDriver"/>
  <option name="jdbcUrl" value="jdbc:odbc:SampleJdbcLogin"/>
  <option name="jdbcUsername" value="sa"/>
  <option name="jdbcPassword" value="password"/>
  <option name="userPreparedStatement" 
         value="SELECT PASSWORD FROM USERS WHERE USERNAME = ? "/>
  <option name="passwordColumn" value="PASSWORD"/>
  <option name="rolePreparedStatement" 
         value="SELECT ROLE FROM USER_ROLES WHERE USERNAME = ? "/>
  <option name="roleColumn" value="ROLE"/>
 </options>
</login-module-entry>
<callback-handler classname="com.cafesoft.cams.auth.callback.NamePasswordCallbackHandler"/> 

Example 4 - Cams Jdbc login module sample

The required JDBC login module options values are:

• jdbcDriver - The fully qualified name of the JDBC driver for your database.
• jdbcUrl - The URL required to access the database (see the JDBC driver documentation).
• jdbcUsername - The username required to access the database (can be null).
• jdbcPassword - The password required to access the database (can be null).
• userPreparedStatement - The SQL prepared statement to select the user's password from the database. The username entered by the the user at login will be substituted for the "?".
• passwordColumn - The table column where the user's password is stored.
• rolePreparedStatement - The SQL prepared statement to select the user's groups/roles from the database. The username entered by the the user at login will be substituted for the "?".
• roleColumn - The table column where the roles are stored.

The JDBC login module supports password digests using Unix Crypt, MD5, and SHA, SMD5, and SSHA. The algorithm is specified within curly brackets in a label that precedes a base 64 encoding of the hashed password (e.g., {CRYPT}, {MD5}, {SHA}, {SMD5}, {SSHA}), which may also include salt bytes.

NOTE: If you need to use a JDBC driver other than the JDBC to ODBC bridge that ships with the J2SDK, you must supply and install the driver. To use the JDBC driver with Cams, copy the driver's jar file the CAMS_HOME/cams/lib directory. Under Linux/UNIX, you will also need to edit runcams.sh and add the driver to the classpath. You can alternatively copy the driver to the ext directory of your J2SDK installation. For example, if you want to use MySQL with the standard J2SDK installation, you would copy mm.mysql-2.0.14-bin.jar to JAVA_HOME/jre/lib/ext.

Using JDBC Connection Pooling

To use JDBC connection pooling from the JDBC login module, you must:

1. Setup a Cams JDBC connection pool service
2. Configure the JDBC login module to use the Cams-provided pooling JDBC driver as shown in example 5
   

<login-module-entry
  className="com.cafesoft.cams.auth.login.module.JdbcLoginModule"
  flag="REQUIRED">
 <options>
  <option name="debug" value="false"/>
  <option name="jdbcDriver" value="com.cafesoft.core.jdbc.PoolingConnectionDriver"/>
  <option name="jdbcUrl" value="jdbc:cafesoft:pool:myusersdb_pool"/>
  <option name="jdbcUsername" value="my_pool_user"/>
  <option name="jdbcPassword" value="my_pool_password"/>
  <option name="userPreparedStatement" 
         value="SELECT PASSWORD FROM USERS WHERE USERNAME = ? "/>
  <option name="passwordColumn" value="PASSWORD"/>
  <option name="rolePreparedStatement" 
         value="SELECT ROLE FROM USER_ROLES WHERE USERNAME = ? "/>
  <option name="roleColumn" value="ROLE"/>
 </options>
</login-module-entry>

Example 5 - Using pooled JDBC connections with the JDBC login module

1. jdbcDriver - use the Cams PoolingConnectionDriver as shown.
2. jdbcUrl - must start with jdbc:cafesoft:pool: and must end with the poolName as configured in the connection pooling service.
3. jdbcUsername and jdbcPassword - use the poolUser and poolPassword credentials specified in the connection pooling service.

All other JDBC login module values are configured as shown in example 2.

LDAP Login Module

You use this login module to access user data that is stored in a directory such as SunOne Directory Server, OpenLDAP, and most other LDAPv3 compliant directories. LDAP directory schema will vary from site to site. This login module if flexible to support many variations of X.500 and DNS style schemas similar to those shown in example 6.

The LDAP login module expects to find a schema similar to the one specified in example 6. The steps the LDAP login module must successfully perform are:

1. Authentication - The user's distinguished name (such as cn=username,ou=people,dc=company,dc=com) is required for authentication. The LDAP login module substitutes the username that the user enters when prompted for authentication against the userPattern parameter. Three password validation methods are available depending upon your security requirements and LDAP server access control settings. The three methods are:
   1. Cams - Retreive the userPassword attribute value and let the Cams LDAP login module do the password validation. The primary advantage of this method is that you can take advantage of all supported Cams password digests, which including Unix Crypt, MD5, MD5 with salt, SHA, and SHA with salt.
   2. Compare - Performs an LDAP compare method call, which delegates the comparison of the user's userPassword attribute to the LDAP server. The primary advantage of this method is performance, the check is performed on the server and a boolean value is returned to the Cams LDAP login module indicating success or failure. Depending upon the LDAP server, the compare method may do hashing to match against a hashed value. This method can be used if the LDAP server access control policy denies userPassword retrieval but allows comparison (especially important if the password is stored in cleartext and the LDAP server is publically available).
   3. Bind - Attempts to bind to the LDAP server using the user's distinguished name and password. If the bind is successful, then Cams authenticates the user. The primary advantage of this method is that it is the only one you can use if the LDAP server access control policy prohibits retreival and comparison of the userPassword attribute. The disadvantage is that binding has a greater performance hit than the other two methods.
      
2. Role Assignment - Once successful authentication is performend, the Cams LDAP login module then performs the role search to retrieve and assign the user roles. Sites often use group attributes for role assignments (though they really are different). You must specifiy the based distinguished name, search scope, search filter, and role attribute name that will be used to find the roles.

The LDAP login module configuration options include parameters to flexibily query user and role information from many LDAP schemas. Your LDAP server may use a schema slightly different from the one specified above that will still work with the LDAP login module. Also, issues with respect to your site LDAP server access control policy may effect the integration with Cams. The recommended approach is to use a general purpose LDAP search tool (usually supplied with your LDAP server) to ensure that your searches return the expected results. Once you acheive success, you can enter the values in login-module.xml and test with Cams. For example, searches such as:

base distinguished name: ou=People,dc=company,dc=com
filter: (ou=myUserName,ou=People,dc=company,dc=com)
scope: one
attributes: userPassword

can be used to determine if the userPassword value can be returned for a user. If your search tool supports sepecification of calling the compare method, you can use similar values with it to determine if a compare can be done. Searches such as:

base distinguished name: ou=Groups,dc=company,dc=com
filter: (uniqueMember=uid=myUserName,dc=company,dc=com)
scope: one
attributes: cn

can be used to determine the roles.

Example 7 shows the sample entry for the LDAP login module.

<login-module-entry
  className="com.cafesoft.cams.auth.login.module.LdapLoginModule"
  flag="REQUIRED">
 <options>
  <option name="debug" value="false"/>
  <option name="host" value="host.company.com"/>
  <option name="port" value="389"/>
  <option name="passwordValidationMethod" value="Cams"/>
  <option name="adminUsername" value="admin"/>
  <option name="adminPassword" value="password"/>
  <option name="userDN" value="uid={username},ou=people,dc=company,dc=com"/>
  <option name="roleBaseDN" value="ou=groups,dc=company,dc=com"/>
  <option name="roleScope" value="ONE"/>
  <option name="roleFilter" 
         value="(uniqueMember=uid={username},ou=people,dc=company,dc=com)"/>
  <option name="roleAttrName" value="cn"/>
 </options>
</login-module-entry>

Example 7 - Cams LDAP login module login-config.xml sample

The required LDAP login module options values are:

• debug - Enables/disables debugging for the LoginModule.
• host - The LDAP server host name or IP address.
• port - The LDAP server port number.
• connectTimeout - (Optional) The number of milliseconds to wait for a connection to the Active Directory before timing out.
• emptyPassword - (Optional) Allow use of empty passwords (false by default). Set this value to true to allow use of empty passwords when the LDAP server is configured for and anonymous binds are required.
• defaultRoles - (Optional) A list of one or more default roles separated by a comma to be added to the user session.
• passwordValidationMethod - Specifies how the LDAP login module will do password validation. Valid values are Cams (validation is done by Cams LDAP login module using password digests), Compare (validation is done by the LDAP server using the compare method call), and Bind (validation is done the LDAP server using an LDAP connection bind call).
• adminUsername - A user account that has access control privleges that allow it to perform searches against the user and role nodes values in the LDAP directory. This value is required when the passwordValidationMethod of Cams or Compare is used, but optional for the Bind method. The Bind method uses the connection bound to the authenticated user to lookup role values.
• adminPassword - The password for the adminUsername account.
• userDN - The distinguished name pattern to match to find a user. The username entered by the the user at login will be substituted for the value "{username}". The LDAP login module will not successfully find users in schemas that use a distinguished name that does not use the username to distinguish users.
• roleBaseDN - The base distinguished name to use for your LDAP schema role searches.
• roleScope - Specifies the LDAP search scope to use for role searches. Valid values are BASE (search is done only at the base dn tree node), ONE (search is done only at the first child tree node of the base dn), and SUB (search is done at the base dn node and all child nodes).
• roleAttrName - The name of the attribute used to store the role names.
• roleFilter - The filter to use to search for a users roles. The username entered by the the user at login will be substituted for the value "{username}".

XML Login Module

Example 10 shows the sample entry for the XML login module. You use this login module to access user data stored in a cams-users.xml directory, found by default in each security domain. This user directory is supplied with Cams for convenience and is not recommend for a large number of users as the entire contents of the file are read into memory.

The XML login module does not process the contents of the cams-users.xml file directly. Instead, it makes use of a Cams service, which loads the XML file and reloads it when modifications are made. This Cams service (defined in security-domain.xml) caches username, password, and role information in memory, greatly improving the efficiency of authentication making it ideal for small user communities that don't change and for authenticating Cams web agents. The path to Cams user directory and the XML handler that knows how to parse the file are specified in the service manager configuration.

<!-- In login-config.xml, register a cams-users.xml directory service -->
<login-config-entry>
 ...
 <login-module-entry
   className="com.cafesoft.cams.auth.login.module.XmlLoginModule"
   flag="REQUIRED">
  <options>
   <option name="debug" value="false"/>
   <option name="serviceId" value="cams-user-repository"/>
  </options>
 </login-module-entry>
 ...
<login-config-entry>

<!-- In security-domain.xml, register a cams-users.xml directory service -->
<service manager>
 ...
 <service id="cams-directory" enabled="true">
  <service-type>com.cafesoft.cams.service.UserRepositoryService</service-type>
  <service-class>com.cafesoft.security.engine.service.UserRepositoryServiceImpl</service-class>
  <param-list>
   <param name="repositoryFilePath"
         value="${cams.security-domain.home}/cams-users.xml"/>
   <param name="repositoryFactoryClass"
         value="com.cafesoft.security.engine.auth.login.userrepository.XmlUserRepositoryFactory"/>
   <param name="handlerClass"
         value="com.cafesoft.security.engine.auth.login.userrepository.CamsXmlUserRepositoryHandler"/> 
   <param name="debug" value="false"/>
  </param-list>
 </service>
 ...
</service-manager>

Example 10 - Sample Cams XML login module as defined in login-config.xml and by the associated security-domain.xml service

The required XML login module options values are:

• serviceId - The unique identifier of the Cams XML user repostiory service (configured in security-domain.xml) that you will use with the XML login module.

The XML login module supports password digests using Unix Crypt, MD5, and SHA, SMD5, and SSHA. The algorithm is specified within curly brackets in a label that precedes a base 64 encoding of the hashed password (e.g., {CRYPT}, {MD5}, {SHA}, {SMD5}, {SSHA}), which may also include salt bytes. See password digests for more information.

See Security Domain Configuration - Cams XML User Repository Service for information on how to configure services.

Callback Handlers

Cams uses callback handlers to pass login credentials from the calling application to the login module. In the web or HTTP space, most webapps use form authentication, typically requesting a username and password for authentication. In this case you can use the Cams NamePasswordCallbackHandler, which takes a username and password as input and provides them to the login module. It is possible to create login modules that require many types of credentials. In some cases you may need to write and register your own callback handler.

To specify a callback handler for use with a Cams login module, each login-config-entry includes the following required tag:

<callback-handler 
  classname="com.cafesoft.cams.auth.callback.NamePasswordCallbackHandler"/>  		 

The Cams JDBC, LDAP, and XML login modules all require the callback handler to supply a username and password. These login modules work well with the NamePasswordCallbackHandler. However, Cams has a pluggable callback framework to associate custom callback handlers with login modules. If the NamePasswordCallbackHandler does not meet your needs, see Cams Callback Handlers to understand how to create a new one. For example, you may want to specify a third authentication credential in addition to username and password, such as the last four digits of a user's social security number or a pin.

Login Parameters

Login parameters are optional tags that help define the login configuration. As shown in example 11, the Cams policy server sends the camsLoginUrl value to a Cams web agent when an access check requires user authentication. The Cams web agent then redirects the user's browser to the camsLoginUrl, which references an HTML form that:

1. Prompts the user for login credentials (e.g., the default NamePasswordCallbackHandler requires form field values cams_cb_username and cams_cb_password for the username and password respectively.
2. POSTs the credentials to the login URL configured by the Cams web agent (/cams/login by default).

The value of camsLoginUrl can be an absolute or relative URL. Any web server with a Cams web agent can be used provided the server is in the same Internet domain as the web server that made the original request.

NOTE: You must change camsLoginUrl to reference a login page at your site. For example, IIS sites might use /cams/login.asp and Apache sites might use /cgi-bin/cams-login.sh.

<login-parameters>
 	<login-parameter name="camsLoginUrl" value="/cams/login.jsp"/>
</login-parameters>

Example 11 - Cams login parameters

NOTE: The value /cams/login.jsp is provided by default. You must change this value to correspond to the login page in use at your site. For example, IIS sites might use /cams/login.asp and Apache sites might use
/cgi-bin/cams-login.sh.

Customizing LoginException Messages

LoginModules throw an Exception when login, commit, abort, or logout actions fails, which provides a way for them to provide additional information on why the request failed. As an administrator, you may want to control or standardize the login failure messages presented to users.

JAAS provides the following standard LoginException classes used by most LoginModule implementations.

• javax.security.auth.login.LoginException - used to indicate a error while trying to authenticate a user. In general, this Exception is thrown by LoginModule implementations to indicate a configuration, connectivity, or runtime error, not a "normal authentication failure".
• javax.security.auth.login.FailedLoginException - used to indicate a authentication failure. For example, a user may not exist, the supplied password may be invalid.
• javax.security.auth.login.AccountExpiredException - used by LoginModules when they determine that an account has expired. For example, a LoginModule, after successfully authenticating a user, may determine that the user's account has expired. In this case the LoginModule throws this exception to notify the application. The application can then take the appropriate steps to notify the user.
• javax.security.auth.login.CredentialExpiredException - used by LoginModules when they determine that a Credential has expired. For example, a LoginModule authenticating a user in its login method may determine that the user's password, although entered correctly, has expired. In this case the LoginModule throws this exception to notify the application. The application can then take the appropriate steps to assist the user in updating the password.

In addition, LoginModule developers are free to create new LoginException subclasses to convey appropriate context for why an authentication request has failed. Cams provides a way for each security domain to define customized LoginException messages based on the class or subclass of the LoginException that may be thrown by a LoginModule. Standard LoginException messages are provided in a file named login-exception.properties in each security domain's home directory.

Example 12 shows the messages defined for the LoginException class and standard subclasses.

#
#--- Customized LoginException error messages. 
#
javax.security.auth.login.FailedLoginException.message=\
       "Authentication failed, invalid credentials"
#
#--- Indicates that a user account has expired.
#
javax.security.auth.login.AccountExpiredException.message=\
       "Authentication failed, account expired"
#
#--- Indicates that a credential (e.g. password) associated with a user
#--- account has expired.
#
javax.security.auth.login.CredentialExpiredException.message=\
       "Authentication failed, credentials expired"
#
#--- Generic LoginException, which is returned if the LoginModule throws
#--- javax.security.auth.login.LoginException or a subclass-specific
#--- message is not defined.
#
javax.security.auth.login.LoginException.message=\
       "Authentication failed, authentication error"

Example 12 - Standard Cams login exception messages defined in login-exception.properties

The actual message returned when a LoginException (or a subclass of LoginException) is thrown by a LoginModule is as follows:

1. If a LoginModule throws javax.security.auth.login.LoginException and property: javax.security.auth.LoginException.message is defined, then the value of this property is returned.
2. If a LoginModule throws a subclass of javax.security.auth.login.LoginException and a property with the exact subclass name followed by .message is defined, then the value of that property is returned.
3. If a LoginModule throws a subclass of javax.security.auth.login.LoginException and a property with the exact subclass name followed by .message is NOT defined, then the value of javax.security.auth.login.LoginException.message is returned.
4. If a LoginModule throws javax.security.auth.login.LoginException or any subclass of that exception, and a corresponding property is NOT defined in this file, then the textual message provided by the LoginModule when it instantiated the LoginException is returned. NOTE: This may be useful for debugging unsuccessful login attempts because LoginModules implementations will sometimes include context sensitive messages. To see only the raw LoginException messages provided by a LoginModule, comment out all properties in login-exception.properties.

To support a context-sensitive message for a subclass of LoginException which is not included in the login-exception.properties, simply add a line of the form:

<LoginException subclass name>.message=Message Text

Example 13 shows a custom Exception used by a fictitious LoginModule that records previous failed login attempts and does not permit additional login attempts for a given period.

#
#--- Indicates the authentication failed due to 3 previous failed login attempts.
#
example.auth.login.MultipleFailedLoginsException.message=\
       "Authentication failed, 3 or more previous login failures. Try again in 2 minutes."

Example 13 - Adding a new login exception message to login-exception.properties

Support for Password Digests

Password digests are one-way hashes that securely store a password using secure, industry standard hashing algorithms. Cams login modules that retrieve the password value from the database implement support for Cams to do digests within the login module. In this case, when a user supplies a password for authentication the Cams login module determines how the password in the user directory was hashed and then uses the same formula to hash the password to be validated. If the resulting digest is the same as the digest stored in the user directory, the user is authenticated.

Cams provides supports for Unix Crypt, SHA (with and without salt), and MD5 (with and without salt) digests. Typically, encryption authorities today recommend use of the SHA algorithm with random salt bytes. For more information on how Cams implements support of digest, see the Password Digests appendix.

Back | Next | Contents

© Copyright 1996-2004 Cafésoft LLC. All rights reserved.