[keycloak-dev] Require password change on login when AD is the federation provider and pwdLastSet equals 0

[Cory Snyder]

Thanks for the suggestions, Marek. I think that overriding the LDAPFederationProvider will be the way to go. The problem that I am seeing which is preventing me from doing this in just the authenticator is that I have no way to authenticate the user in order to allow them to update the password unless I also make changes to the LDAPFederationProvider. As you mentioned, the LDAPFederationProvider simply returns false from the validCredentials method when the pwdLastSet attribute equals 0. If I don’t authenticate the user with their current password beforehand, it would allow anyone with the username to change the user’s password. Or am I overlooking something?

Thanks,

Cory Snyder
software engineer
USA +1.419.731.3479   UK +44.20.7096.0149    iland.com<http://www.iland.com/>

On Nov 10, 2015, at 8:32 AM, Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>> wrote:

Btv. I think it should be possible to do it with authenticator as well, but you need to configure authentication flow correctly. You will have your custom authenticator, which will check pwdLastSet and if it's 0, it will put the requiredAction on user and at the same time it will set user as authenticated. It would need to be ALTERNATIVE authenticator used in browser flow before "Forms" authenticator (Forms authenticator is that one which displays login form with username/password and optionally OTP). That way, forms authenticator won't be used and username/password form won't be displayed. It will go directly to requiredActions and user will be asked to update password.

Marek

0On 10/11/15 14:27, Marek Posolda wrote:
I agree we need some way to address this. Active Directory is widely used and more people asked for that . I've put the comment to https://issues.jboss.org/browse/KEYCLOAK-1744 with possible solution, but it may need changes in UserFederationProvider interface, so the federationProvider is able to propagate the cause why password validation failed (password is expired, user is disabled, or just invalid password was used etc...).

As a temporary workaround, you can subclass LDAPFederationProvider and do something on your own. You can override LDAPFederationProvider.validPassword and add updatePassword on User when you detect that reason of password validation failure is expired password.

Marek

On 09/11/15 20:32, Cory Snyder wrote:
Hey guys,

Following up on this conversation that took place a couple of months back: http://lists.jboss.org/pipermail/keycloak-dev/2015-September/005286.html. I just had a chance to try the proposed approach of implementing a custom authentication provider that checks the pwdLastSet attribute and sets the update password required action. I believe that this may not be quite as easy as was suggested due to the fact that authentication fails with the default LDAP Federation Provider before a custom execution in the login flow has a chance to check the attribute and set the required action. It seems I would need to implement a custom LDAP Federation Provider that considers authentication successful when the exception referenced in <https://issues.jboss.org/browse/KEYCLOAK-1744> https://issues.jboss.org/browse/KEYCLOAK-1744 is thrown, but also add the required action for updating the password. Is there an easy way to do that or something that I’m missing? Otherwise, I’d be willing to work on a contribution for this issue if you’re willing to have logic that is specific to AD?

Thanks,

Cory Snyder
software engineer
USA +1.419.731.3479   UK +44.20.7096.0149    iland.com<http://www.iland.com/>




_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev




_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151110/1d14976a/attachment-0001.html