7:40 a.m.
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@redhat.com<mailto:mposolda@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@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev