Access and Authentication

Advanced Access Control and username case sensitivity

Share this post:

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.

Click here to rate this article

Rate this article :

More stories
By Jeroen Tiggelman on August 4, 2019

IBM Security zSecure Suite 2.4 announced

IBM Security zSecure suite V2.4 was announced on July 23, 2019 with a planned availability date of September 30, 2019. You can read the US announcement letter here. RACF has made new JSON Web Token functionality in support of Multi-Factor Authentication also available for z/OS V2.2 and V2.3. Details about zSecure compatibility fixes can be […]

Continue reading

By Martin Schmidt on July 11, 2019

Modernizing your B2C Portal Security – LDAP Proxy Deep Dive

In this part of our series we are taking a deeper look on how the LDAP reverse proxy works and what is needed to be done to make it work. Enable CI In this part we look at what needs to be done on the CI side and what information needs to be collected. We […]

Continue reading

By Martin Schmidt on May 17, 2019

Modernizing your B2C Portal Security – A thoughtful approach

As we have described the situation that many of our customers are in today, and our proposal for a better future state, we come to realize that for many, this transition is a journey, and a single big bang transition is not practical for many.  This blog entry will outline an approach to start such […]

Continue reading