On 09/27/2012 11:05 AM, MARCON Bruno wrote:
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) ?.
The most typical use case would simply be reading/searching for the
userId attribute to be used as key to find corresponding Fortress
UserAssignation object. But for more advanced requirements, I
anticipate a need for (any or all) of the following:
authentication, password policy evaluation, and retrieval of
attributes to be considered within Fortress RBAC runtime, i.e. AD
groups. Our callback could thrown an exception, return with a code,
and update reference to data objects and/or bag containing common
properties.
It would be a very simple interface:
int validate(User user) throws ValidationException;
Part of the contract would be for Fortress to look for certain
return codes to determine whether to proceed with creating the rbac
session or throw an exception.
On 09/27/2012 11:05 AM, MARCON Bruno wrote:
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.
That would be very beneficial to us. Thank you.
On 09/27/2012 11:05 AM, MARCON Bruno wrote:
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.
Here are the attributes that UserAssignation must store in order for
Fortress to still be able to perform its RBAC, ARBAC and Audit
duties:
ftUID - Fortress user id <--- a new attribute, and
perhaps the only that is required. This maps back to whatever is
stored in external directory.
These are optional. Some are for RBAC role, some are for ARBAC
role, some hold temporal constraints for role or user:
ftRC - Fortress User Role Constraints
ftRA - Fortress User Role Assignments
ftARC - Fortress Admin Role Constraints
ftARA - Fortress Admin Role Assignments
ftCstr - Fortress User Temporal Constraint
ftSystem - Fortress System User
ftOSU - Fortress User Organizational Unit Pool
These are for fortress audit purposes and are not updated by the
application:
ftModifier - Fortress Audit Modifier Internal UserID
ftModCode - Fortress Audit Modifier Operation Code
ftModId - Fortress Audit Modifier Unique ID
On 09/27/2012 11:05 AM, MARCON Bruno wrote:
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.
Yes or we could just use a default OS-U for non-managed users?
|