Hi all,
I'm trying to get a grasp of how LDAP is working in DSpace 1.4.2, with
or without patches.
DSpace docs and some earlier posts suggest that LDAP authentication in
1.4.x is enabled by setting:
ldap.enable = true
plugin.sequence.org.dspace.eperson.AuthenticationMethod = \
org.dspace.eperson.LDAPAuthentication
However, sporadic posts and some stuff on SourceForge suggests that
ldap.enable is "unnecessary". There's also stuff on SourceForge
suggesting that stackable authentication is "broken". And there's a mail
by Christophe Dupriez (18 Nov 2007) suggesting that the
LDAPAuthentication class is an "untested embryon", while other posts
suggest that LDAPServlet is obsolete (even though it seems to be the
class doing the hard work!)
All this is rather contradictory, as it seems that both the
"unnecessary" ldap.enable AND the "untested embryon" LDAPAuthentication
are needed in order to have LDAP enabled and working in an unpatched,
off-the-shelf DSpace 1.4.2. In fact, this combination of "unnecessary"
and "untested" LDAP stuff works fine. It gives me exactly the end user
experience that I want: a logon screen prompting for username OR email,
and accepts either. The only thing it doesn't give me is support for
hierarchical LDAP, which I badly need (users reside in several different
OU's.)
Now, there is this patch #1597831 on SourceForge which eliminates the
"unnecessary" ldap.enable, "fixes" the apparently broken stackable
authentication, and introduces support for hierarchical LDAP (yay!). It
seems to work (except for when browsing deeper in Active Directory), but
there are some odd things about it. First off, when clicking on My
Dspace, I get a page where I have to choose authentication method.
Cumbersome. What's more, REGARDLESS of which method I choose (and get
redirected to ldap-login or password-login respectively), I can use
either an LDAP username or a dspace account to log in! Why prompt the
user for which method to use, if both "methods" accept both types of
credentials? Also, if invalid credentials (neither valid LDAP nor valid
dspace eperson) are supplied at ldap-login, the "try again" page is
served by password-login. Very, very confusing for the end user and for
the admin/developer..
So, what I'm wondering is: if I need to change the LDAP code somewhat in
order to get LDAP working against multi-OU Active Directory, should I
hack the original DSpace 1.4.2 code (which is confusing with its
LDAPServlet vs LDAPAuthentication split), or should I carry on working
with the 1597831 patch (which is confusing in terms of user experience)?
Or should I sit tight and wait for 1.5 and hope that this jungle has
been sorted out by someone else?
best regards,
Mathias Hjelt
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
