directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] [Commented] (DIRSERVER-1926) Supply Entry to PasswordValidator instead of username
Date Thu, 05 Dec 2013 16:22:37 GMT


Emmanuel Lecharny commented on DIRSERVER-1926:

Thanks for the patch !

We will study it soon.

One comment though : you can use the @ in a DN, it's allowed. It depends just on the attribute
you are using for that.

> Supply Entry to PasswordValidator instead of username
> -----------------------------------------------------
>                 Key: DIRSERVER-1926
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 2.0.0-M15, 2.0.0-M16
>            Reporter: lucas theisen
>            Priority: Critical
>              Labels: features, patch
>         Attachments: AuthenticationInterceptor.patch,
> It is very common that PasswordValidation has a requirement to ensure a login name is
not part of the password.  It is also common to use a 2 phase authentication in which an attribute
of the user Entry is used to lookup the DN and then bind against the dn.  Most commonly you
see an email based lookup.  Since @ is not allowed in a DN, you cannot use mail as the RDN.
 So, if you want to validate the the actual login name is not part of the password you will
need the entry (as it could be any attribute that is used for the lookup).  My proposed solution
will maintain backwards compatibility while allowing for this new validation at the same time
by adding PasswordValidator2 which extends PasswordValidator adding a validate that takes
an Entry for the username, then in the AuthenticationInterceptor I change the add and modify
methods to supply Entry to the check method which then check the type of PasswordValidator,
and if type is PasswordValidator2, then uses the validate with the Entry.  You will find patches
> As a workaround I have to extend your AuthenticationInterceptor, override add, modify,
and check with 99% identical code which would be rather unmaintainable as the project moves
forward.  So hopefully you will choose to integrate this into the core...

This message was sent by Atlassian JIRA

View raw message