One of the features that has been changed over the last few releases of the Oracle Utilities Application Framework has been security. To keep up with security requirements across the industry, the Oracle Utilities Application Framework utilizes the security features of the infrastructure (Operating System, Oracle WebLogic and Oracle Database) as well as provide inbuilt security capabilities. One of the major capabilities is the support for Hash Keys on the user identity.
On the user object, there is a hash key that is managed by the Oracle Utilities Application Framework. The goal of this hash key is to detect any unauthorized changes to the user identity and prevent users from being used after an unauthorized change has been done. From an Oracle Utilities Application Framework point of view, an unauthorized change is a change that is done without going through the user object itself. For example, if you issued an UPDATE statement against the user tables directly, that did not go through the user object. That is an example of an unauthorized change.
When a user record is accessed, for example at login time, the Oracle Utilities Application Framework recalculates the hash key and compares that against the stored hash key. If they match, then the user is authorized, using the authorization model, to access the product. If the hash key does not match, then the user record has been compromised and the user action is rejected. In the case of a login, the user is refused access to the product.
The log will contain the message:
User security hash doesn't match for userid
From time to time we get customers reporting issues with these same characteristics. In most cases, this is caused by a number of practices:
- User Object Updated Directly. Some implementations update the user object via direct SQL for a particular reason. This technique is discouraged bypasses the business rules configured for the user object within the product. We recommend that customers update the user object via the provided methods to prevent the user becoming recognized as compromised. The user object is protected by the authentication and authorization model used.
- Encryption Key has been changed. At some sites, the encryption key is rotated on a regular basis. When this happens, the hash key becomes stale and needs to be rebuilt to reflect the new key.
These are the only two use cases where the hash key becomes invalid. So what can be done about it? Well there are two techniques that are suggested to resolve this issue:
- Manually resolve the issue. The hash key is rebuilt upon update of the user object using the maintenance function (user interface or user object directly). Use an alternative valid authenticated and authorized user, to edit the invalid user object and saving the user object will regenerate the hash key. This is recommended for spot problems with low numbers of users. This technique is available, with configuration, in web services, plugin batch or request/request type processing if necessary.
- Synchronize Data Encryption Utility. The Oracle Utilities Application Framework provides a command line based utility to reset hash keys (and other encryption related information) on-masse. This utility is documented in the Security Guide supplied with your product in the section named Synchronize Data Encryption. It is recommended to use this utility to reset the user hashs when the problem is widespread. See also CCB and C2M V2.6.0.0.0 Demo Install Error User Security Hash Doesn't Match For Userid When Logging Into Environment (Doc Id 2270728.1), MDM 2.2 Hash Key Generation (Doc Id: 2359462.1) and 'resource [/loginError.jsp], because it is stale' Because User Security Hash Doesn't Match (Doc Id: 2054791.1) available from My Oracle Support.
Note: The utility will set all the hash's not just the invalid ones.
It is recommended not to alter the User Object directly without going through the user object to avoid security hash issues.