Olivier, I only have answers to a couple of your questions, but perhaps that helps a little bit...
First: I have the same situation here. Authentication against LDAP works, but the data is not collected correctly from the LDAPserver. All I get is a local entry with the netid, but nothing else (phone number, email, real name etc. are not taken). So I would be very interested how you got that part working... I have created a helper script, which is asking the LDAP for database entries, which are missing in our DSpace DB. That solves the problem, but its still only a workaround. And this leads me to a more general remark: why creating eperson for a user loged in with LDAP? I guess thats because every object (for example items) in DSpace needs to have an eperson, who created it. If this eperson (no matter how it was authenticated) creates an item, DSpace needs to store the internal ID of that eperson for reference. Otherwise the "My DSpace" area could not work. If a user, who was authenticated via LDAP, is removed from the LDAP, I guess he cannot login into DSpace, because he has no password and though he shouldn't be authenticated successfully. But, to be honest, I haven't tried that yet. In the other points I agree with you: it should not be necessary to copy the personal data into the local database, but read it on demand from the directory, because this is causing update trouble. I also do not understand, why the search has to be anonymous. Best regards Oliver Am 22.01.2015 um 09:34 schrieb Olivier Nicole: > Hi, > > OK, I have some answers but it raises much more questions. > >> enable = true >> autoregister = true >> provider_url = ldaps://ldap.cs.ait.ac.th/ >> id_field = uid >> object_context = ou=People,ou=csim,dc=cs,dc=ait,dc=ac,dc=th >> # search_context = ou=People >> email_field = mail > It stubornedly refuses to work. > >> surname_field = sn >> givenname_field = givenName >> phone_field = telephoneNumber >> #login.specialgroup = CSIM_LDAP >> search_scope = 2 >> #search.anonymous = false > This MUST be set to true in order to have autoregister working. > >> #search.user = cn=admin,ou=people,o=myu.edu >> #search.password = password >> #netid_email_domain = @example.com >> #login.groupmap.1 = ou=ldap-dept1:dspace-group1 >> login.groupmap.attribute = csimAccountPermission > This attribute can only have *ONE* value. > >> login.groupmap.1 = dspace:CSIM_LDAP >> login.groupmap.2 = dspaceadmin:Administrator > - So the autoregister of the email is not working (name, phone are working > great). I tried with one or two values for the mail attribute, could not > get it to work. I can live with that as users are located in the same > domain as DSpace and email can be sent with only the username. > > - The login.groupmap.attribute cannot have several values, I think I can > live with it and manage the group hierarchy some other way if I want a > user to belong to 2 groups. > > - But what is really puzzling me is why the search has to be anonymous? > The user has provided a username and password, these have been used to > successfully bind to LDAP, then the search should be made as the user, > not as anonymous (hopefully the user has more visibility to his own > data than anonymous has; if the telephone number should not be made > world visible for security readon, when bind as the user, the user > should be able to see his own phone number). > > So the anonymous search should be used only when trying to figure out > the DN of the user in a hierarchical LDAP. It should not be used to > gather the personnal information once the user has successfully > bind. Or there is a case i don't understand where the bind DN is > different fro the DN that contains the user detail? > > And this leads me to a more general remark: why creating eperson for a > user loged in with LDAP? > > - when the LDAP account is removed, the user can still login using is > eperson account (provided that he has updated his profile and > installed a password); so when a user is leaving the system, he must > also be deleted from DSpace; > > - when the LDAP account is updated, the eperson must be updated in the > same way; > > - there is no major difference between finding the person details in LDAP > and in Postgres; one should not take longer than the other. > > Best regards, > > Olivier > > > > > ------------------------------------------------------------------------------ > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashburn. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant. > http://p.sf.net/sfu/gigenet > _______________________________________________ > DSpace-tech mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech > List Etiquette: > https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
