Calculation of expiration date time by default accommodates cases where it's basically based on an expiration attribute value, or it's based on a date attribute value + some leeway. While these two are fine for default, sometimes you'd have to go through more to actually figure out what the expiration date should be. In those cases, the handler would have to be extended, and allowing the developer to rewrite this method would satisfy that use case.
Recently had a discussion with folks who expressed interest in leveraging the LPPE bit of the handler to reach out to other non-ldap systems to perform calculations. This would allow one for instance to authenticate via ldap, but for instance leverage an external JDBC connection to make do with calculating the expiration date and so on. I believe this change helps to accommodate those who have disparate account stores for user identity and management, etc.
Trivial
Expose the retrieval and calculation of expiration date via the "protected" access level:
protected DateTime getExpirationDateToUse(final PasswordPolicyResult result) {Calculation of expiration date time by default accommodates cases where it's basically based on an expiration attribute value, or it's based on a date attribute value + some leeway. While these two are fine for default, sometimes you'd have to go through more to actually figure out what the expiration date should be. In those cases, the handler would have to be extended, and allowing the developer to rewrite this method would satisfy that use case.
Recently had a discussion with folks who expressed interest in leveraging the LPPE bit of the handler to reach out to other non-ldap systems to perform calculations. This would allow one for instance to authenticate via ldap, but for instance leverage an external JDBC connection to make do with calculating the expiration date and so on. I believe this change helps to accommodate those who have disparate account stores for user identity and management, etc.