On 19/04/2016 13:41, Emmanuel Lécharny wrote:
Le 19/04/16 11:39, Achilleas Mantzios a écrit :
On 19/04/2016 12:20, Emmanuel Lécharny wrote:
Le 19/04/16 10:47, Achilleas Mantzios a écrit :
Hello,
I have been testing sporadically openldap two years now, including
many advanced features, sql, ppolicy, etc we are currently evaluating
openldap along with redhat's 389 for enterprise use as RBAC, on which
we will built upon our existing infrastructure. We want to have full
password policy enabled, in order to meet requirements for passing SOX
(Sarbanes Oxley) compliance.
389's documentation is lousy, I haven't tried anything exotic (sql,
etc) with it, the reason we are looking at it is because it is favored
by kolab.org and likely to come as standard in future kolab versions.
So I would like your opinion on this. Pros/Cons to choose openldap or
389 directory server as our long term strategic decision?
If you are interested in RBAC, know that there is a Java API that
implements RBAC athttp://directory.apache.org/fortress/ (1.0.0 have
just been released last week). It works with OpenLDAP as a backend (and
some other LDAP server too).
Hi I had talked with a SYMAS person some years ago regarding fortress,
this is also hosted by openldap :http://www.openldap.org/fortress/
So who manages fortress?
It has moved to the Apache Foundation 2 years ago.
Thanx for the insight.
By the test we had done with openldap it seemed that marginally we
could meet our password policy requirements.
Here, you will have to tell us more about your requirements.
Right, we have an inhouse application running on Java EE, which we have been
developing for the last 16 years. We use mostly classic form-based j2ee
declarative security. We have been using IBM Lotus Notes Domino Server and its
bundled LDAP server, by writing our own login module for Jboss. But lotus's
LDAP is of limited potential. Now we need to have the following features :
- support password strength and also communicate relevant error codes/messages
back to the calling client (e.g. jboss login module)
- handle correctly while in period of passwd expiration warning (error
codes/messages)
- handle correctly after period of passwd expiration, but within the grace
limit (error codes/messages)
- support password history (error codes/messages)
- handle correctly after period of passwd expiration, and also after grace
limit (error codes/messages)
- account explicitly locked (error codes/messages)
- handle pwdMustChange & pwdReset (error codes/messages)
- account explicitly locked after pwdMaxFailure (error codes/messages)
According to some tests we had done back in 2014, we had it all covered, in
theory. Our idea was to have some supplementary roles assigned to the user,
denoting of any outstanding state of the account, and then add this role to
the user, inside the login module, and then use an hybrid approach of
declarative security + some filters + some programmatic security to allow the
user to have a full RBAC experience