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 theAltLogin
column indicates whether theUserName
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úramExtendedUsersInfo
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 defaultDBtoJMS
username used by batch processing and is referenced by propertycuram.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 propertycuram.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
andExtendedUsersInfo
tables.
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
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.