<securityPolicy> ... <credentials> <password> <valuePolicyRef oid="fef1df42-0a63-11e7-a916-a384c93fd2d0"/> </password> </credentials> </securityPolicy>
There are many password-related configuration items in midPoint:
Password Policy is used to enforce password strength (complexity). This is configured in Value Policy objects referenced from Security Policy objects.
Password lifetime parameters (e.g. expiration) can be configured in Security Policy object.
Password history setting is configured in Security Policy object.
Password storage scheme is configured in Security Policy object.
Most of the password-related settings are located in the Security Policy object where also policies for other credential types are located.
See Password Policy page.
Use Security Policy object to reference password policy:
Direct password policy references are deprecated since midPoint 3.6.
When password history is enabled then midPoint will remember the passwords that the user has used in the past. Then midPoint will enforce uniqueness of a new password when the user ties to change the password.
<securityPolicy> ... <credentials> <password> <historyLength>10</historyLength> </password> </credentials> </securityPolicy>
When this setting is applied then midPoint will remember last 10 passwords.
Since midPoint 3.6 the password policy entries will be stored in a hashed form. The history entries were stored in encrypted form in midPoint 3.5.1 and earlier. Storing password history in hashed form is more secure. However it will prohibit application of password policies that depend on approximate likeness of new password and historical passwords. Only exact matches will be possible if password history is stored in a hashed form. The password history storage scheme can be set in the security policy configuration.
Existing password reuse
Since 4.3This functionality is available since version 4.3.
When password history is enabled, once the password was set it can never be reused again by default. That perfectly makes sense for many scenarios. Now think of a situation, that you synchronize password to 10 different resources using the focus password as your source. One of the resources throws network error, password is not changed there, while 9 other resources got password propagated nicely. Focus password is saved as well and history appended. Now what you want to do is set password to the failed resource again. In the default scenario, you cannot do that, since password is already in the history and cannot be reused. Luckily we have a option in midPoint to allow that under certain circumstances.
The option historyAllowExistingPasswordReuse allows en existing focus password (last set password) to be reused and set again to the same value as the new password. However, when maxAge constraint is set, value cannot be reused after existing password has expired. If set to false, user must always provide fresh password when setting the new password. This setting is effective only when historyLength > 0. Default behaviour is that reuse is not allowed (setting is false).
<securityPolicy> ... <credentials> <password> <historyLength>10</historyLength> <historyAllowExistingPasswordReuse>true</historyAllowExistingPasswordReuse> <maxAge>P180D</maxAge> </password> </credentials> </securityPolicy>
Password Storage Schemes
Since 3.6This functionality is available since version 3.6.
See Password Storage Configuration page.
Starting with midPoint 3.6 all password-related configuration should be done by using the Security Policy object. The direct password policy references in system configuration or organizations are now deprecated.
However, there is one exception: Resource password policy in the resource definition should still be reference directly. This is referencing the resource password policy. There is not security policy defined for the resources.
The password lifetime setting in the password policy (Value policy) objects is deprecated. It is only partially implemented anyway. Do not use this. Use the security policy settings instead.