External Database Password Repository
It is typically used in cases where the Default Password Repository does not work:
- The passwords are stored in a database different from the user database.
- In self-registration flows (where there is no in-memory user that is persisted automatically).
userStore) allowedPasswordValidityDuration) If a password is changed, the 'latest password change timestamp' is set and, if this property is defined, the 'next enforced password change timestamp' is updated.
If this property is not defined, the 'next enforced password change timestamp' is not updated.
hashFunction) Note that the password hash function may or may not support password history checks. If the configured password hash function does not support password history checks but a policy checker requires this capability, an exception is thrown when trying to change a password.
NOTE: Some password hashes, such as SHA 256 Password Hash or Scrypt Password Hash, produce binary output. If one of these is used, make sure the persistence layer supports binary data in the hash field and the corresponding persistence plugins (e.g. Database User Store or Ldap Connector) are configured to treat hash values as binary values.
In case the persistence layer expects a string, encode the password hash by wrapping it with an encoder. To achieve this, use the Password Hash Configuration plugin and specify the hash function (such as Scrypt Password Hash) together with the desired encoder. We recommend using the Base64 Password Hash Encoder.
legacyHashFunctions) If the password cannot be verified using the main "Hash Function" above, all hashes in this list are tried as well. If any hash of this list matches, the password is stored using the current main hash function (see property "Hash Function"). In this case, a potential password history is lost.
This feature allows changing the password hash function with automatic migration of all users that log in.
Notice that having a legacy hash function in this list producing the same output length as the main hash function can pose a security risk since it might be possible for an attacker to provoke a match using a weaker hash method.
useLatin1Encoding) If enabled, passwords containing special characters stored by IAM earlier than 6.3 are still accepted. This option does not have to be activated if all passwords were set using IAM 6.3 or later or if all passwords were set via webservices or REST.
To support legacy passwords, those with special characters are additionally checked using their legacy encoding in latin1 and if matching, they are rehashed and stored using the current hash function. In this case, a potential password history is lost.
type: ExternalDatabasePasswordRepository
id: ExternalDatabasePasswordRepository-xxxxxx
displayName:
comment:
properties:
allowedPasswordValidityDuration:
hashFunction:
legacyHashFunctions:
useLatin1Encoding: false
userStore: