RE: Split user management

[MARCON Bruno <Bruno.MARCON@thalesgroup.com>]

Hi Shawn.

The Client's LDAP must not be modified because the client does not want to modify its LDAP schema. Eventually, Fortress could read any user's information from the Client's LDAP if needed.
The problem is when a new user is added by the client in its LDAP, the FORTRESS OPENLDAP is not notified of this new user. It is then impossible to assign this user to roles using the FORTRESS API because the user does not exists in the FORTRESS OPENLDAP.

I see two solutions : 

1) - LDAP Synchronization
A synchronization is needed between the Client LDAP and the FORTRESS OPENLDAP. In this way, users created in the first LDAP are created in the FORTRESS OPENLDAP. This needs the client LDAP to have a replication mechanism or a notification mechanism on user creation.

2) - Client LDAP access
FORTRESS can access the LDAP in READ access only. FORTRESS should be configure to read users from a specified LDAP, not necessary the FORTRESS OPENLDAP. However, perhaps some LDAP like Active Directory have not the same schema that OpenLDAP and it is not possible for FORTRESS to read users from Active Directory because the schema are not the same ? Or FORTRESS uses a standard schema ?
Furthermore, FORTRESS needs to update users after a user-role assignation (adding for example the role id in the users roles owned). Because users can not be modified in the Client's LDAP, FORTRESS needs to managed a new entity/class in its own LDAP. It does a lot of job perhaps to manage a new entity and enable to read users from any LDAP.


So I don't know how to cleanly implements a solution based on FORTRESS that enable to managed role and authorization, but that do not manage users.

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
Office:  +33 (0)1 69 41 60 96
Fax:       +33 (0)1 69 41 55 63


-----Message d'origine-----
De : Shawn McKinney [mailto:shawn.mckinney@joshuatreesoftware.us] 
Envoyé : lundi 10 septembre 2012 12:37
Cc : MARCON Bruno; openldap-fortress@openldap.org
Objet : Re: Split user management

On 09/07/2012 08:57 PM, Shawn McKinney wrote:
> More questions: What interactions should Fortress have with the 
> external directory - should it be capable of binding, reading user 
> attributes, i.e. group assignments? What about provisioning - should 
> the Fortress AdminMgr APIs be capable of provisioning user data into 
> the external directory?
One point needs to be clarified here:

If the intent is not to maintain interactions in the manner pointed out 
above, you should be able to use Fortress alongside the user management 
system of your choice today.  The fortress user object still needs to be 
provisioned, but the password and user demographics data need not be 
loaded nor maintained.

When utilizing Fortress in this manner, don't set the User's password 
attribute but do set the the 'isTrusted' boolean parameter to 'true' 
when you call the createSession API.

     public Session createSession(User user, boolean isTrusted)
         throws SecurityException;