Hi Mathias,
This is what I think has happened - Until 1.4 you had the option of using
the standard login or the LDAP login. If you set ldap.enable=true then you
would be directed to the LDAPServlet and the LDAP login screen. In fact, as
you describe, LDAPServlet also allowed for 'traditional' login if the id was
of the form of an email address, otherwise it assumed it was an LDAP id. I
haven't seen Dspace 1.4 but I have played with 1.5. There is now no need to
set ldap.enable=true, intead you specify a stack of authentication classes
eg
#### Stackable Authentication Methods #####
# Stack of authentication methods
# (See org.dspace.authenticate.AuthenticationManager)
plugin.sequence.org.dspace.authenticate.AuthenticationMethod = \
org.dspace.authenticate.PasswordAuthentication, \
org.dspace.authenticate.LDAPAuthentication
I had expected that the authentication would 'fall through' the stack ie if
you failed the password authentication the you would be passed on to the
LDAPAuthentication. However, I was surprised when I was asked to choose
which authentication method I wanted to use (chooser.jsp). This is not
really what I want and I may have to change the code so that the user does
not get a choice. In addition the new class
org.dspace.authenticate.LDAPAuthentication does contain a comment to say it
is untested. Whenever we migrate to 1.5 I will test it but I don't know when
this will be.
Not sure if that helps or just confuses matters further.
Cheers, Robin.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mathias
Hjelt
Sent: 17 January 2008 07:03
To: [email protected]
Subject: [Dspace-tech] DSpace LDAP jungle
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
-------------------------------------------------------------------------
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
