Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C25FF10906 for ; Thu, 5 Dec 2013 17:08:52 +0000 (UTC) Received: (qmail 30523 invoked by uid 500); 5 Dec 2013 17:08:44 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 30406 invoked by uid 500); 5 Dec 2013 17:08:40 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 30280 invoked by uid 99); 5 Dec 2013 17:08:36 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Dec 2013 17:08:36 +0000 Date: Thu, 5 Dec 2013 17:08:36 +0000 (UTC) From: "lucas theisen (JIRA)" To: dev@directory.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (DIRSERVER-1926) Supply Entry to PasswordValidator instead of username MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/DIRSERVER-1926?page=3Dcom.atlas= sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D= 13840281#comment-13840281 ]=20 lucas theisen commented on DIRSERVER-1926: ------------------------------------------ As I side note, because you are not at an official release yet, it is under= stood that you may change the interfaces. That said, I think passing the E= ntry is much more correct than just a username. Corporate validation rules= often include exclusion of personal information in a password. By passing= the whole Entry, it makes it possible to verify that cn, sn, givenName, ma= il all are not part of the password. =20 However, it could be frustrating for others who have already implemented Pa= sswordValidator's if you do change the interface, though I certainly would = not mind... > Supply Entry to PasswordValidator instead of username > ----------------------------------------------------- > > Key: DIRSERVER-1926 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1926 > 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, PasswordValidator2.= java > > > It is very common that PasswordValidation has a requirement to ensure a l= ogin 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 th= e DN and then bind against the dn. Most commonly you see an email based lo= okup. 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 passw= ord you will need the entry (as it could be any attribute that is used for = the lookup). My proposed solution will maintain backwards compatibility wh= ile allowing for this new validation at the same time by adding PasswordVal= idator2 which extends PasswordValidator adding a validate that takes an Ent= ry for the username, then in the AuthenticationInterceptor I change the add= and modify methods to supply Entry to the check method which then check th= e type of PasswordValidator, and if type is PasswordValidator2, then uses t= he validate with the Entry. You will find patches attached. > As a workaround I have to extend your AuthenticationInterceptor, override= add, modify, and check with 99% identical code which would be rather unmai= ntainable as the project moves forward. So hopefully you will choose to in= tegrate this into the core... -- This message was sent by Atlassian JIRA (v6.1#6144)