Interface PasswordPolicy

All Known Implementing Classes:
ReferencePasswordPolicy

@PublicSpi public interface PasswordPolicy
Provides a mechanism for rejecting proposed passwords. Some example reasons might include:

  • The password must be at least 8 characters long.
  • The password must not contain your username.
  • The password must not contain a year within the past century.
  • The password must not be similar to your previous password.
  • The password can not repeat any of the previous 4 passwords that you have used.
  • The password can not be based on a dictionary word.

... and so on.

Since:
v6.1
  • Field Details

    • DUMMY_ID

      static final Long DUMMY_ID
  • Method Details

    • validatePolicy

      Collection<WebErrorMessage> validatePolicy(@Nonnull ApplicationUser user, @Nullable String oldPassword, @Nonnull String newPassword)
      This will be called when a user attempts to change a password. Returning a non-empty list of WebErrorMessage will prevent the new password from being accepted.
      Parameters:
      user - the user whose password would be changed. This will never be null, but if the intent of the request is to create a new user, then the user will not yet exist and services like the UserManager and ApplicationUsers.from(User) will not be able to resolve it. The user's directory ID and ID will be -1 for this case.
      oldPassword - the user's existing password, or null if that information is not available, either because this is a new user or because an administrator is changing the password
      newPassword - the user's proposed new password
      Returns:
      a collection of WebErrorMessages explaining why the password cannot be accepted
    • getPolicyDescription

      List<String> getPolicyDescription(boolean hasOldPassword)
      Returns a list of rules that passwords must follow to satisfy the policy.
      Parameters:
      hasOldPassword - whether or not the request concerns the rules when the old password is provided. This is true for the case where an existing user is changing his/her own password, but not when an administrator is changing another user's password or a new account is getting created. The rule list should probably be different for these cases. For example, it does not make sense to tell an administrator that the new password can not be similar to the old password when the administrator does not even know what the old password was. Nor does it make sense to say this to a new user, for whom the whole idea is completely irrelevant.
      Returns:
      a list of rules that passwords must follow to satisfy the policy.