The following update to core.PasswordPolicyState.java, along with some small changes to consumers of its API are the result of a review in preparation for password policy state management extended operation (issue 579).

1. Issue 1301 Force Pwd Change Option Allows User to Change Pwds But Not Bind With New Pwd

I had made a change to PasswordPolicyState.setMustChangePassword in a previous commit that did not account for the possibility that the PasswordPolicyState field could be ConditionResult.UNDEFINED. Now the routine calls mustChangePassword, which ensures the state field is set.

2. Issue 1295 PwP: PasswordPolicyState.setRequiredChangeTime uses incorrect time value

Per https://opends.dev.java.net/public/docs/architecture/OpenDS-PWPolicy-Architecture.pdf , the field is to be set to the value of ds-cfg-require-change-by-time. It was being set to the PasswordPolicyState field passwordChangedTime value.

3. Issue 1344 PwP: PasswordPolicyState field secondsUntilUnlock set inside debug condition. Moved outside.

4. Issue 1346 PwP: When lockout-due-to-failures expiration detected, pwdFailureTime timestamps must be cleared. Now cleared along with pwdAccountLockedTime.

5. Initialize PasswordPolicyState fields at declaration, when a default initial value is available. Otherwise, the field is qualified with final, to help ensure proper initialization. (Similar to recent change to PasswordPolicy.)

6. Fixed several errors introduced when the new debug{Error,Warning,Info} methods were introduced and the string concatenation message style was replaced with the printf format string message style.

7. Converted getPasswordPolicyInternal to a static method: while the password policy state computation depends on the policy object, it is not a part of the state, per se. The method could be made public and used for AddOperation.

8. Changed PasswordPolicyState.getBoolean to return ConditionResult to be consistent with other entry field getters (i.e., indicate when the attribute is absent from the entry).

9. Used canonical attribute access style for getPasswordValues (for loop) to accommodate absent attribute and empty attribute values (based on attribute getters used throughout the existing code).

10. For the policy state getters, reorganized to follow a canonical structure:
    a. Return if cached value is found (note that lazy initialization is used for state fields).
    b. Try to fetch attribute value from entry.
         i. Handle exception case.
         ii. Handle absence case.
    c. Perform any computation on entry value needed to arrive at state value; store state value.
    d. Return result.

11. Revised PasswordPolicyState.lockedDueToFailures feature. The feature is complicated by the use (due to the IETF draft) of two state attributes. This change attempted to simplify managing the feature by wrapping the attribute management into a simpler API.
      a. Narrowed public API to
          i.  updateAuthFailureTimes:  adds pwdFailureTime timestamp and [new] checks for lockout;
          ii. lockedDueToFailure: checks for pwdAccountLockedTime, another lockout corner case, and handles lockout expiration including [1295] clearing pwdFailureTime timestamps;
          iii. clearFailureLockout: clears pwdAccountLockedTime and [new] pwdFailureTime.
       b. Factored pwdAccountLockedTime getter/setter/clear from public API. These are called from the public API as appropriate.
       c. Also, it now accommodates the pwdAccountLockedTime:19700101000000Z as a valid locked time (but subject to lockout expiration and not as "locked until reset" as described in IETF draft-behera).

12. Note that PasswordPolicyState.mustChangePassword is unusual in that it does not evaluate the entry unless the policy indicates the feature is enabled (i.e., checks for allow-user-change and force-change-on-{add,reset}). I did not change this behavior, but marked it with FIXME.

13. PasswordPolicyState.clearWarnedTime: Added getWarnedTime() and warnedTime = -1 to make it consistent with other clear routines.

14. PasswordPolicyState.getClearPasswords, passwordMatches, and handleDeprecatedStorageSchemes duplicated code for authPassword and userPassword syntax. Combining the two cases was complicated by the fact that these two routines have different return types:

  StringBuilder[] AuthPasswordSyntax.decodeAuthPassword
  String[] UserPasswordSyntax.decodeUserPassword

I did not change either return type, but believe the return types should be consistent.


TESTS

There are no unit tests. The functional tests (security) provide some coverage (e.g., like finding 1301), and these 157 tests now pass.