IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

Advanced Access Control and Username Case Sensitivity

By Jasmine Smith posted Tue January 08, 2019 12:00 AM

  
Usernames can come from many different sources these days. They can be randomly generated by the service, user chosen, or an attribute of the user like their email address or mobile phone number. Whether the username is case sensitive can be dependent on the service provider, or the identity provider in federated flows. Like many implementation choices, the decision to treat the username as case sensitive is a trade off between usability and potential added security.


Prior to IBM Security Access Manager (ISAM) 9.0.3, several Advanced Access Control (AAC) features would assume that usernames were case sensitive. These features include:

  • OAuth tokens and trusted clients
  • MMFA/IBM Verify
  • FIDO U2F authentication
  • Browser/device fingerprinting


Considering the Web Reverse Proxy processes usernames as case insensitive, this can lead to confusion or errors for end users, as well as duplication of data. For example, if “user1” logs in as “User1,” they could be prompted to re-register when already registered, or be unable to find the data they expect.

A change was made in ISAM 9.0.3 to ensure AAC would always treat usernames as case insensitive without needing to migrate any data. However, this fix was found to potentially degrade performance during high load peak periods.

ISAM 9.0.4 reverted that change, and instead included code to operate intelligently depending on how ISAM was installed.

In fresh installations:

- Case insensitivity is enabled out of the box
- Usernames are stored as all lowercase
- Search requests on the features listed temporarily lowercase usernames when used in SQL commands


In upgraded installations:

- Case insensitivity is disabled out of the box
- Usernames are stored as supplied with case preserved
- Manual migration is required to enable case insensitivity

So what do I do?


If you are working with only fresh installs from 9.0.4+, wonderful! Your AAC is already case insensitive.

If you are on a version less than 9.0.3 and you want to enable case insensitivity, upgrade to the latest version of ISAM (or any version 9.0.4+) then follow these steps.

Internal database deployment: Install the fixpack as described by: http://www-01.ibm.com/support/docview.wss?uid=swg22007256

External database deployments: Execute the following SQL statements against the Runtime database:

UPDATE AUTHENTICATORS SET USERNAME=LOWER(USERNAME);
UPDATE MMFA_AUTH_TXN_DATA SET USERNAME=LOWER(USERNAME);
UPDATE OAUTH20_TOKEN_CACHE SET USERNAME=LOWER(USERNAME);
UPDATE OAUTH_TRUSTED_CLIENT SET USERNAME=LOWER(USERNAME);
UPDATE RBA_USER_DEVICE SET USER_ID=LOWER(USER_ID);
UPDATE RBA_USER_USAGE_DATA SET USER_ID=LOWER(USER_ID);
UPDATE U2F_TOKENS SET USERNAME=LOWER(USERNAME);
UPDATE USER_ATTRIBUTES SET USER_ID=LOWER(USER_ID);


The Schema Updates table name may contain a “HV” prefix, so run the relevant command below:

INSERT INTO DB_SCHEMA_UPDATES VALUES (CURRENT_TIMESTAMP, 198711069, 'username.legacyBehavior');


OR

INSERT INTO HVDB_SCHEMA_UPDATES VALUES (CURRENT_TIMESTAMP, 198711069, 'username.legacyBehavior');


Then restart the LMI, and voila! You have now enabled username case insensitivity.

How can I check?

You can check whether case insensitivity is enabled or disabled by checking the Advanced Configuration parameter username.legacyBehavior.

If username.legacyBehavior is set to true, AAC will treat usernames as case sensitive.

If username.legacyBehavior is set to false, AAC will treat usernames as case insensitive.

Note: username.legacyBehavior is a read-only parameter.




#ISAM
5 comments
37 views

Permalink

Comments

Mon March 16, 2020 11:54 PM

Hi @Jan Brokate,
If the Advanced Configuration entry is not automatically updating after an LMI restart, there may be an issue with either one of the SQL commands, or connectivity to the database. That is why it is not recommended to update the configuration directly.​

Thu March 12, 2020 05:05 AM

Hi @Jasmine Smith,
sorry I forgot to mention, that your blog article is extremly important and helpful! Many thanks again for sharing this!

Let me clarify my comment please: I've seen several cases where after excecution of all these SQL statements listed above and after LMI restart, unfortunately USERNAME.LEGACYBEHAVIOR in the Configuration database was still not updated.
That's why I've added this UPDATE sql statement against the Configuration database to be complete just for this situation when the ISAM_OVERRIDE_CONFIGS value won't be automatically updated.
​​

Sun February 23, 2020 06:14 PM

Hi @Jan Brokate​,
That's not entirely accurate. If all the SQL statements listed in the blog article are executed, then the LMI is restarted, the ISAM_OVERRIDE_CONFIGS value will be automatically updated. There is no need to modify the parameter directly.

Fri February 21, 2020 09:36 AM

You also need to execute the following SQL statement against the Configuration database:
UPDATE ISAM_OVERRIDE_CONFIGS SET CONFIG_VALUE = 'FALSE' WHERE CONFIG_EXTERNAL_KEY = 'USERNAME.LEGACYBEHAVIOR';


Then restart the LMI

Sun December 01, 2019 10:58 PM

Thank you Jasmine. It was informative. Regards,