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 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
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev