RE: [Dspace-tech] LDAP - Search

[John Finlay]

The LDAP authentication in DSpace first attempts to bind to the LDAP
server using the username and password provided by the authenticating
user. Once bound to the server it can then search the LDAP for the
user's properties and set them in the DSpace EPerson record. The
options in the dspace.cfg file allow you to append the correct DN to the
username entered by the authenticating user.

I have seen cases where users have different DN's. In this case you
will have to modify the LDAPServlet.java file to first bind with a
privileged LDAP account, and search by the given username for the
correct DN. Once you have the correct DN, you can bind again to LDAP
using that DN and the password entered by the user. This double bind
authentication scenario would probably be good to have as an option in
DSpace, if somebody wants to do it and submit a patch.

If your regular users cannot bind to the LDAP server, then you will need
to modify the LDAPServlet.java file to first bind with an approved
account, and then search the LDAP directory, and then perform some kind
of authentication check against the data that is returned.

--John


-----Original Message-----
From: dspace-t...@lists.sourceforge.net
[mailto:dspace-t...@lists.sourceforge.net] On Behalf Of Ashwin
Kutty
Sent: Wednesday, September 21, 2005 7:53 AM
To: DSpac...@lists.sourceforge.net
Subject: [Dspace-tech] LDAP - Search

I am trying to currently setup DSpace to allow for LDAP authentication
with our local directory but in vain. The problem is that we do not
have a DN per say, as much as we have an rdn. The DSpace LDAP code
however, only looks for the uid/id field rather than running a search
through the LDAP directory to find the dn and then authenticate against
it.

Has anyone come across this issue and solved it? Would it require an
external authentication script (I did one in PHP for one of our other
applications and can tie it in for DSpace as well)?

Thanks.

Ashwin.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
DSpace-tech mailing list
DSpac...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

[Mark H. Wood]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 21 Sep 2005, John Finlay wrote:
> The LDAP authentication in DSpace first attempts to bind to the LDAP
> server using the username and password provided by the authenticating
> user. Once bound to the server it can then search the LDAP for the
> user's properties and set them in the DSpace EPerson record. The
> options in the dspace.cfg file allow you to append the correct DN to the
> username entered by the authenticating user.

That is definitely too simple for the general case.

> I have seen cases where users have different DN's.

I should think so. You can't have two objects with the same Distinguished
Name. I think we're actually talking about multiple contexts -- that is,
some User objects are subordinate to one OU, others to another, and so on:

CN=mwood, OU=Library, O=Our University
CN=jsmith, OU=Engineering, O=Our University

rather than one big pile of User objects in a single container. Back when
we ran Netware 4, I did something like that so that departments could
easily manage their own accounts.

> In this case you
> will have to modify the LDAPServlet.java file to first bind with a
> privileged LDAP account, and search by the given username for the
> correct DN.

Perhaps not so very privileged. The binding DN's object need only have
enough privilege to search from the search-base DN on down as far as the
search depth requires. In many directories every user has such
privileges. I've used my own plain-vanilla user account for the initial
bind when testing authentication of new services. But I can imagine
settings in which that wouldn't work.

> Once you have the correct DN, you can bind again to LDAP
> using that DN and the password entered by the user. This double bind
> authentication scenario would probably be good to have as an option in
> DSpace, if somebody wants to do it and submit a patch.

Apache's mod_auth_ldap does that, for example.

- --
Mark H. Wood, Lead System Programmer mw...@IUPUI.Edu
Open-source executable: $0.00. Source: $0.00 Control: priceless!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/

iD8DBQFDMscUs/NR4JuTKG8RAqDPAKCpaZawtf9bnEDuLaFpAs32iM8SNwCbBqoH
4o4Z//m4gmxPDDBAyaPkC4M=
=sLsg
-----END PGP SIGNATURE-----

[Keith Jones]

Hi,

I'm in the middle of bringing up a fresh install of version 1.3 and I'm
getting the following error.

load_registries:
[java] 2005-09-22 14:16:42,430 FATAL
org.dspace.administer.RegistryLoader @
anonymous::error_loading_registries:
[java]
java.io.FileNotFoundException: /dspace/config/registries/bitstream-formats.xml
(No such file or directory)
[java] at java.io.FileInputStream.open(Native Method)
[java] at
java.io.FileInputStream.<init>(FileInputStream.java:106)
[java] at java.io.FileInputStream.<init>(FileInputStream.java:66)
[java] at
sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:69)
[java] at
sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:156)
[java] at
org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
[java] at
org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown
Source)
[java] at
org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
[java] at
org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
[java] at org.apache.xerces.parsers.XMLParser.parse(Unknown
Source)
[java] at org.apache.xerces.parsers.DOMParser.parse(Unknown
Source)
[java] at
org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
[java] at
javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:151)
[java] at
org.dspace.administer.RegistryLoader.loadXML(RegistryLoader.java:284)
[java] at
org.dspace.administer.RegistryLoader.loadBitstreamFormats(RegistryLoader.java:156)
[java] at
org.dspace.administer.RegistryLoader.main(RegistryLoader.java:104)

BUILD FAILED
/export/home/carr/dspace/dspace-1.3-source/build.xml:307: Java returned: 1



Can anyone give me an idea as to what is going wrong with the install.

Thanks

[Ashwin Kutty]

[Keith Jones]

Please disregard my previous message. I downloaded the correct src files.