|
This means the APIs would either work as default, or split, but never both simultaneously. (are we still good?) Yes, we are still good J. 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). This callback only enable authentication ? Or there is some other needs (than display a window to select a user and do the authentication) ?. 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. I think we can build (here at Thales) a demonstrator using a LDAP (Active Directory) and FORTRESS and test your new FORTRESS Package with user management split. Notes: 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. In fact, the Object class User can be rename UserAssignation, and be clean of unused attributes. Only two attributes will remains I think : User role assignation and OS-U assignation. A question can be : when the client install the FORTRESS solution without management, all users in its directory will have no OS-U assignments. Perhaps a first thing will be to fill a object UserAssignation for each user in the directory, and ask to the administrator, the OS-U to set for each user. 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. These requirements are good and necessary it seems, but we have no use case from our business lines or clients about this for the moment. We think it will be necessary in the future because of the increase of security treats. Integrity and Non repudiation are critical functionalities for authorization systems. 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 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----- 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. 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----- 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. |