Achilleas Mantzios wrote:
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)
Certainly OpenLDAP addresses all of this already.
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
Fortress is still the only complete ANSI RBAC implementation around. Seems like this is a pretty obvious choice.