directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: [Fortress] UnboundID replacement plan
Date Thu, 16 Oct 2014 11:46:32 GMT
Le 16/10/14 12:56, Kiran Ayyagari a écrit :
> On Thu, Oct 16, 2014 at 1:13 PM, Emmanuel Lécharny <>
> wrote:
>> Hi !
>> as we decided to replace the UnboundId API by the Apache Ldap API, we
>> have a bit of work to do, and we need a plan for that.
>> 1) API selection
>> Currently, Fortress uses the two APIs, though some configuration that
>> tells which one to use. We can now get rid of this configuration and
>> remove completely the classes that uses the UID API. We typically have
>> classes for the 2 libs :
>> o UnboundIdDataProvider
>> o ApacheDsDataProvider
>> Those two classes are doing the exact same thing, and are the base for
>> many other classes (the DAO : AcceleratorDAO, AdminRoleDAO, AuditDAO,
>> ConfigDAO, OrgUnitDAO, PermDAO, PolicyDAO, RoleDAO, SdDAO, UserDAO). We
>> have to inherit from the ApacheDsDataProvider for all those classes now.
>> 2) DAO romoval
>> As we had two data provider, we also had two classes for each DAO, one
>> per data provider. We can now get rid of the UID DAO, which are in
>> org.openldap.fortress.rbac.dao.unboundid.
>> 3) DAO Interface removal
>> It would make sense to also get rid of the DAO interfaces, if we are to
>> use only one single implementation. We could just merge the interface
>> and the classes.
>> That should be an easy task, as we won't have a lot to do to have it
>> working : the Fortress code is already able to handle those two APIs.
>> There are only one thing we have to troubleshoot, and it's related to
>> the passwordPolicy management. I don't exactly remember what's the
>> problem, but from the top of my head, it's just that the Apache LDAP API
>> doesn't have a way to define the attributeType which will store the
>> password. That might requires a sligth modification in the Apache LDAP API.
>> are there any real world usecase that need this password attribute mapping?
> or are we just trying to allow this flexibility as per the ppolicy draft?
It's in the RFC draft :


   This holds the name of the attribute to which the password policy is
   applied.  For example, the password policy may be applied to the
   userPassword attribute.

         NAME 'pwdAttribute'
         EQUALITY objectIdentifierMatch
         SYNTAX )

View raw message