Alternate Login IDs

By default, Cúram uses the username and digested password that is stored in the Cúram Users table for authentication. The username cannot be changed after it is created and the lack of flexibility might not meet requirements for some installations. Therefore, you have the option of configuring an alternate login ID that can be updated. However, if the default security implementation that is configured during installation meets your requirements, it is not necessary to configure an alternate login ID.

The login ID functions as a logical extension of the Cúram Users table. When the alternate login ID is used the username still exists and is used internally by Cúram, but the user logs in to Cúram by using the login ID.

Things to note when using the alternate login ID:

  • The Cúram users can log in with their alternate login IDs if available or user names if not. When the property alternate login is disabled, users are only allowed to log in with their user names.
  • The Cúram ExtendedUsersInfo table, where the login ID is stored, must be populated before the application turns on the alternate login ID feature, which is explained in more detail in the following explanation.
  • When using login IDs, authentication results are stored in the AuthenticationLog table and the AltLogin column indicates whether the UserName column represents a username (false) or login ID (true).
  • Login IDs are only applicable to internal Cúram users; that is, users stored on the Cúram Users table. However, if you are using identity-only with alternate Login IDs then wherever those IDs are stored (for example, WebSphere® registry, Lightweight Directory Access Protocol (LDAP), and so on) must match the login IDs stored in the Cúram ExtendedUsersInfo table.
  • When assigning login IDs, you need to take care with IDs that are used internally or have dependencies (for example, with property values) outside of the Cúram Users table. These IDs are the user names that would cause issues if theirlogin ID differed from the username without a corresponding change as indicated:
    • SYSTEM - In WebSphere this user name is associated with Java Message Service (JMS) processing and is made part of the WebSphere configuration at application deployment time. For more information on changing this ID, see Mandatory Cúram Users and the appropriate WebSphere Cúram Deployment Guide.
    • DBTOJMS - this value is the default DBtoJMS username used by batch processing and is referenced by property curam.security.credentials.dbtojms.username. For more information, see Mandatory Cúram Users, JMS Messaging, andDeferred Processing the Cúram Batch Processing Guide.
    • WEBSVCS - this value is the default web services username and is referenced by property curam.security.credentials.ws.username. For more information, see Mandatory Cúram Users, Web Services, and the Cúram Web Services Guide.
    • Unauthenticated - is the principal WebSphere uses for unauthenticated users and this login ID should not be changed.

To enable the use of the alternate login ID, after you have populated the ExtendedUsersInfo table, set the curam.security.altlogin.enabled property to true (for more information on Cúram properties, see the Cúram Server Developer's Guide). This value is a static property and Cúram must be restarted for it to take effect.

When the curam.security.altlogin.enabled property is set to true, authentications are not processed directly through the user name column in the Cúram Users table. Instead, authentications are all processed through the ExtendedUsersInfo login ID, which references the Cúram Users table.

Along with the introduction of support for an alternate login ID, the administrative pages for adding, updating, and displaying Curam users have been extended to include the new Login ID field. The Login ID field is displayed only when the corresponding curam.security.altlogin.enabled property is set to true.

To populate the ExtendedUsersInfo table (see table that follows for ExtendedUsersInfo you have a number of options; for instance:

  • With a simple SQL statement, you can populate the table by using the user name in the Users table; so, there is no immediate user impact: INSERT INTO EXTENDEDUSERSINFO (USERNAME, LOGINID, UPPERLOGINID, VERSIONNO) (SELECT USERNAME, USERNAME, UPPER(USERNAME), 1 FROM USERS); You can then roll out your modifications to the login IDs in a controlled manner.
  • You can implement an SQL application that implements your user name and login ID mapping (for example, LDAP common names).
    Note: You must maintain the user name foreign key relationship between the Users and ExtendedUsersInfo tables.
Table 1. ExtendedUsersInfo Table Structure
Name Type Size Description
USERNAME VARCHAR 256 Username is an immutable string. This field has a foreign key relationship with username field in Users table.
LOGINID VARCHAR 1280 Login ID is associated to the user name and can be updated. The login ID functions as a logical extension of the Cúram Users table. Users can log in to Cúram application by using Login ID.
UPPERLOGINID VARCHAR 1280 Login ID in uppercase. Uppercase login ID is used for supporting case-insensitivity.
Version No VARCHAR 4 Version Number.

Configuring internal and external users

If you have both internal and external users, extra calls might occur to the getRegisteredUserName() method in the ExternalAccessSecurity class. The security cache calls the getRegisteredUserName() method if the login ID is not found in the security cache. Therefore, all internal and external login IDs and user names must be unique, unless the curam.util.security.UserScope interface is implemented. Otherwise, an external user that matches a login ID might be found in the security cache and therefore not found as an external user. If a login ID can't be found either in the cache, or through the External Access Security implementation if it is provided, then an INFRASTRUCTURE.INFO_LOGIN_ID_DOES_NOT_MAP_TO_USERNAME exception occurs.

Configuring a custom alternate login implementation

A customer can set the curam.citizenworkspace.alternate.login.implementation property to point to a custom alternate login implementation, as shown in the following example:
curam.citizenworkspace.alternate.login.implementation=curam.citizenworkspace.security.impl.SampleCitizenWorkspaceAlternateLogin
A customer can use the alternate login implementation to specify custom code that returns the user name when an alternate login ID is submitted. The alternate login implementation must extend the CitizenWorkspaceAlternateLogin abstract class and provide an implementation for the getRegisteredUsername(final String loginId) method.