Re: Split user management

[Shawn McKinney <shawn.mckinney@joshuatreesoftware.us>]

On 09/26/2012 09:29 AM, MARCON Bruno wrote:
> 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.
Just so I understand, let's take an example API, createSession.

As you know this API first binds with OpenLDAP (and evaluates password 
policies), second it builds the RBAC 'session' (pulled from aux object 
class as previously described) containing activation attributes like 
roles and such.

In this hybrid scenario of yours, the createSession API may bind against 
client's LDAP rather than default OpenLDAP (of course the actual bind 
step may be bypassed by setting 'trusted', second the API will pull the 
activated roles from a new object class - UserRoleAssignation (perhaps 
that still uses same aux object classes to contain the role assignments) 
that is provisioned in OpenLDAP.

We would also extend some of the other APIs (review and admin) to work 
with the new object class, UserRoleAssignation, rather than the default 
iNetOrgPerson.

This extended behavior must be configurable by a switch within the 
fortress properties.  That is to say when the property is set for 
'default' the APIs behave the way they behave today.  When the property 
is set for 'split' user management it would behave in the manner I just 
described.

This means the APIs would either work as default, or split, but never 
both simultaneously.  (are we still good?)

There would also be the need for a callback routine (executed during 
createSession) authentication step (assuming the implementor has config 
set to be split).  The callback would be a customization for the 
implementor to code the bind to their preferred directory (or database!) 
and even evaluate password policies per their LDAP's method (if need be).

We would supply the common ones as part of the Fortress package.  For 
example, binds with Active Directory, would be ready out-of-the-box to 
use.  Binds into custom or non-standard environments would need to be 
coded by the implementor and dropped into the fortress classpath during 
runtime.  The config switch would contain the class name of the custom 
routine so fortress would know how to instantiate and use.


On 09/26/2012 09:29 AM, MARCON Bruno wrote:
> 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.
Assuming we are both describing the same thing, it would not be 
difficult, and yes we would be willing to do this.  I would of course 
rely on your help to ensure we code to the requirements and test when 
its done.


On 09/26/2012 09:29 AM, MARCON Bruno wrote:
> 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.
We will need to discuss more to make sure I understand fully but these 
are sound concepts that are good and necessary as well.  Should be able 
to support these requirements as well.