You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2014/10/16 09:43:42 UTC

[Fortress] UnboundID replacement plan

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.

Now, it's just a part of the whole story. The other big task is to
complete the "mavenization" of the code, but I'll write another mail for
this task...

Please feel fee to comment !

Thanks !

Re: [Fortress] UnboundID replacement plan

Posted by Shawn McKinney <mc...@att.net>.
On 10/16/2014 02:43 AM, Emmanuel Lécharny wrote:
> 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.

Assuming we want to perform the work to remove unbound dependency & the DAO interface/impl layer before the actual import to the new apache directory git repo.  We could then get it fully functional (pw policies/etc with apache ldap api) once it is in the new repo.

Re: [Fortress] UnboundID replacement plan

Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 16/10/14 12:56, Kiran Ayyagari a écrit :
> On Thu, Oct 16, 2014 at 1:13 PM, Emmanuel Lécharny <el...@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 )

Re: [Fortress] UnboundID replacement plan

Posted by Kiran Ayyagari <ka...@apache.org>.
On Thu, Oct 16, 2014 at 1:13 PM, Emmanuel Lécharny <el...@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?

> Now, it's just a part of the whole story. The other big task is to
> complete the "mavenization" of the code, but I'll write another mail for
> this task...
>
> Please feel fee to comment !
>
> Thanks !
>
>


-- 
Kiran Ayyagari
http://keydap.com