directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: [Fortress] UnboundID replacement plan
Date Thu, 16 Oct 2014 10:56:57 GMT
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?

> 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

Mime
View raw message