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

RE: Split user management



If we do not accept users exists in two different directories (or we don't want or be able to develop any connectors or listeners for all possible LDAP), the best solution will be that Fortress read users directly in the Client LDAP, and only fill attributes/information into ObjectClass of FORTRESS OpenLDAP. Information stored actually in attribute of the User ObjectClass (like role id and constraints on user role assignation ?) should be stored into a new ObjectClass named UserRoleAssignation.

In this way, FORTRESS will be able to read user from any LDAP compliant with LDAP-V3, and use its own OpenLDAP to manage Role management.

In the case of Clients having no LDAP and no user management at all, a default solution is to use FORTRESS APIs and FORTRESS OpenLDAP to manage users (the current solution).
If this client want to use a new User management solution, and a new LDAP, he will just have to import its users in the new LDAP and configure FORTRESS to read the new Client's LDAP. All others information remains unchanged in the FORTRESS OpenLDAP.

Is this possible with FORTRESS, with a few development ? Or is this totally impossible or needs to much development ?
I remember our problem is to let the client to choose its LDAP or/and its User management solution.

If FORTRESS was able to give this flexibility to clients, it will be really a interesting authorization solution !

The only needs after that will be to optionally store roles and user-role assignations into Attributes certificates, to add integrity and security, and non-repudiation functionalities (user X have delegate role Y to user Z). Optionally because some clients will ask for security and integrity, with an increased cost of the solution, while others will prefer to use the standard solution without increased cost.

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é : mardi 25 septembre 2012 23:43
À : MARCON Bruno
Cc : openldap-fortress@openldap.org
Objet : Re: Split user management

On 09/24/2012 11:10 AM, MARCON Bruno wrote:
> 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.

Understood.  This is an expected scenario.  One thing to keep in mind as we carry this conversation forward, Fortress uses inetorgperson to store its attributes except for what is needed for the RBAC.  For RBAC we use auxiliary object classes that are combined with the standard.  That way a client can store user data in their native ldap/object class (inetorgperson, person, organizationalperson,...) even though the fortress attributes reside on same object.

With the exception of password policies and audit, fortress is LDAPv3 which means its APIs will work with any LDAPv3 compliant directory including Active Directory.

The catch is, as you pointed out, most will not allow their schema to be touched - especially for an enterprise directory like AD.  This is the case despite the fact that with the use of auxiliary object classes to store the rbac data, there would be no impact to resident data elements and processes.

On 09/24/2012 11:10 AM, MARCON Bruno wrote:
> 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.

Yes that would work using an LDAP listener.


On 09/24/2012 11:10 AM, MARCON Bruno wrote:
> 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.
>

AFIK AD uses inetorgperson for users so obviously we will have no trouble reading and binding with those objects regardless of which ldap it is in.  The tricky thing is ensuring the synch process works effectively in detecting when a change occurred on client side.  It will be another process that resides in client datacenter which will require care and feeding which they probably will not like.

I think your two solutions are actually part of a single solution.  That is we use #1, LDAP listener to detect change, and when change is triggered use #2 to read the changes from client's ldap and load new data (for roles and such) into the fortress controlled ldap.

There is a 3rd option here to exploit OpenLDAP's native capability function like a virtual directory to aggregate the two data sources into a single data view.  Binds would occur with the client's ldap and authorizations would occur within fortress' ldap.  OpenLDAP would aggregate the two into one for fortress, and the fortress API would shield details from the caller so no matter what the deployment scenario the business operations always act the same.