[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Split user management



I think a extension point is a good idea. Password policies management is useless because the client's user management handle the passwords and password policies. Fortress without user management don't care of password policies and users.

Using an InetOrgPerson as an object class is a good idea because at the beginning, we can do the hypothesis that client's user management will be only LDAP. But perhaps others kinds of user management could be handled with some specific development.

The big problem I think, is actually fortress fills attributes in Roles stored and Users stored in the LDAP. If Users are no more stored and managed in OpenLDAP, Fortress must create new objects to manage USER-ROLE assignations. For exemple a USER-ROLE assignation object with attributes describing the role owned for a user and the constraints on this role assignation (time period, day period, etc.).

Best regards,

Bruno Marcon
ThereSIS Innovation lab, ICT Security Unit
 - IT Security Expert
 - Software Architect

Thales Research & Technology
Campus Polytechnique
1, avenue Augustin Fresnel
91767 Palaiseau cedex
France

-----Message d'origine-----
De : openldap-fortress-bounces@OpenLDAP.org [mailto:openldap-fortress-bounces@OpenLDAP.org] De la part de Shawn McKinney
Envoyé : vendredi 7 septembre 2012 14:21
À : openldap-fortress@openldap.org
Objet : Re: Split user management

On 09/07/2012 07:00 AM, Bruno.MARCON@thalesgroup.com wrote:
> So if we want to use Fortress in our system, we must split the user management part from Fortress functionalities. Is there a simple way do to this, like rewrite our override the UserDAO class ?

Bruno, agreed that we need to handle this requirement.  Overriding the UserDAO is one way to do this.  Would need to add an extension mechanism to handle cleanly.  Just to make sure we're on same page here.  We want user data, including userid, password, pw policies and user demographic info like name, address, phone, email to reside in external directory.  Can we standardize on a particular ldap object class, i.e. inetOrgPerson? Or for that matter can we assume the user information is stored in a directory?  One more question: How would you expect password policies to be handled as those are specific to the directory implementation that manages the password?