Alternate Login IDs

By default, Cúram utilizes the username and digested password stored in the Users table for authentication. This username is immutable, once created it cannot be changed. This lack of flexibility may not meet requirements for some installations. However, you have the option of using a login ID, which can be updated, instead of the immutable username. 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 into Cúram using the login ID.

Things to note when using the alternate login ID:

• The use of the alternate login ID is mutually exclusive with the username. That is, you cannot have a mix of Cúram users logging in with usernames and login IDs.
• The Cúram ExtendedUsersInfo table, where the login ID is stored, must be populated before turning on the alternate login ID feature, which is explained in more detail below.
• 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; i.e., 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 (e.g. WebSphere® registry, LDAP, etc.) 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 and/or have dependencies (e.g. with property values) outside of the Cúram Users table. These are the usernames that would cause issues if its login ID differed from the username without a corresponding change as indicated:
  • SYSTEM - In WebSphere this username is associated with JMS processing and is made part of the WebSphere configuration at application deployment time. See Mandatory Cúram Users and the appropriate WebSphere Cúram Deployment Guide for information on changing this ID.
  • DBTOJMS - this is the default DBtoJMS username used by batch processing and is referenced by property curam.security.credentials.dbtojms.username. See Mandatory Cúram Users, JMS Messaging, Deferred Processing and the Cúram Batch Processing Guide for more information.
  • WEBSVCS - this is the default web services username and is referenced by property curam.security.credentials.dbtojms.username. See Mandatory Cúram Users, Web Services, and the Cúram Web Services Guide for more information.
  • 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, once you've populated the ExtendedUsersInfo table, set the curam.security.altlogin.enabled property to true (see the Cúram Server Developer's Guide for more information on Cúram properties). This is a static property and Cúram must be restarted for it to take effect.

To populate the ExtendedUsersInfo table before activating the feature you have a number of options; for instance:

• With a simple SQL statement you can populate the table using the username 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 username and login ID mapping (e.g. LDAP common names).
  Note: You must maintain the username foreign key relationship between the Users and ExtendedUsersInfo tables.