directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
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 <elecharny@gmail.com>
> 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 :


        5.2.1
        <https://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-5.2.1>.
        pwdAttribute



   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.

         ( 1.3.6.1.4.1.42.2.27.8.1.1
         NAME 'pwdAttribute'
         EQUALITY objectIdentifierMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )




Mime
View raw message