I've had this discussion probably nearly 100 times with different
clients and different people, and been involved in over a dozen
different LDAP and SSO implementation. Based on that and reading this
a few things come to mind:
1. only put in LDAP what other applications can share, since that is
the whole point: sharing data in standard structures (as much as such
things exist...); putting as much as possible into LDAP only adds
effort with no reward, and in fact can cause performance and other
problems compared to having that data in a database
2. the flows and touch points for different means of authentication do
differ, so no single authentication object or something could be used
for everything; for example most SSO stuff either looks for an HTTP
header (as with the one now in SVN) or looks for an encrypted
parameter or a parameter that can be looked up by talking to another
system to prove the identity of the prospective user; on the other
hand the LDAP stuff involves the entry and verification of a username
and password, it's just that the data is checked against the LDAP
server instead of the database; even with an LDAP server or SSO it
doesn't mean you can get rid of the UserLogin entity, as it relates to
other various other entities, unless the user is only a user and there
is no party/contact/role/relationship/etc information needed for them;
as has been mentioned permissions for a user could also go into LDAP
(in some cases... not all though) which means the user wouldn't
necessarily need a UserLogin record for that, but other things... :
( ... hello redundancy and more flexibility but more maintenance (some
of which can/should be automated of course); BTW, this is true for ALL
apps that support LDAP authentication, not just OFBiz, and in fact if
you look at what certain other apps do it is pretty lame :)
3. in general it is a best practice to implement things manually and
separately, and THEN look for redundancies and clean up, refactor, and
consolidate the code once more is known; this helps avoid many
mistakes and missteps, which unfortunately often make their way into
OFBiz, and possibly even this discussion
-David
On Jun 19, 2008, at 11:54 AM, Adrian Crum wrote:
It looks like we finally have a decent implementation for
authenticating users using LDAP - https://issues.apache.org/jira/browse/OFBIZ-811
. This will allow OFBiz installations to share user names and
passwords with the network.
I would like to expand it further so that OFBiz user permissions can
be managed outside OFBiz - using LDAP directory management tools. It
would be very convenient in an LDAP (or Active Directory)
environment to treat OFBiz user permissions just like any other
network resource.
There are other authentication technologies that could be used this
way also - like Single Sign On, Radius, and so forth.
In a previous discussion it was suggested we could put a "mini LDAP
server" within OFBiz to accomplish this. The concept is to have a
network's LDAP server forward requests to OFBiz. OFBiz would then
serve its data in LDAP form.
At first I thought that was a great idea, but now I'm not so sure. I
believe it would be better to consolidate authentication and
permission checking, and then make the whole thing "swap-able." An
OFBiz installation could then swap OFBiz's entity-based user
authentication and permission checking with some other technology -
like LDAP, SSO, etc.
The problem with implementing something like this is the way user
authentication and user permissions checking are handled in the
existing code. The two are separate - handled by separate classes in
separate components. In addition, the CRUD services for permissions
are in a third component. Clearly, there needs to be some
consolidation.
At the least, we need to have the org.ofbiz.security.Security
interface expanded to have an authentication method and methods for
permissions CRUD operations. Each authentication technology could
then have its own implementation of the interface. An OFBiz
installation could be configured to use any of the available
technologies using the security.context property in the
security.properties file.
What do you think?
-Adrian
