This is a bit of a guess, but we had a client for which we needed to implement authentication support for OpenAM through the REST API. To do this, we back ported the DSpace 6 REST authentication framework to DSpace 5. We then encountered a similar issue.
The problem is that when a user logs in using LDAP or Shibboleth, they do that using a some kind of username or user ID and not their e-mail address. This has the effect that the DSpace 6 DSpaceAuthenticationProvider creates a UsernamePasswordAuthenticationToken with that user name (which is not an e-mail address): https://github.com/DSpace/DSpace/blob/master/dspace-rest/src/main/java/org/dspace/rest/authentication/DSpaceAuthenticationProvider.java#L63 Later on, this user name is used to lookup the ePerson account based on his e-mail address: https://github.com/DSpace/DSpace/blob/master/dspace-rest/src/main/java/org/dspace/rest/Resource.java#L91 BUT THIS IS WRONG, since the user name is mostly not the e-mail address of that user. We fixed this by adding a method createAuthenticationToken to the DSpaceAuthenticationProvider that will store the authenticated ePerson's e-mail address in the Spring Authentication object, instead of the user name used to login: https://github.com/milieuinfo/dspace54-atmire/blob/ontwikkel/dspace/modules/rest/src/main/java/org/dspace/rest/authentication/DSpaceAuthenticationProvider.java#L65 That solved the problem for us, since the logic in the REST Resource class is then correct. I do not have access to a development Shibboleth or LDAP system so I cannot test if this will also fix the problem in the official DSpace 6 code, but I'm pretty confident it will. Can someone who has a development Shibboleth and/or LDAP, apply this fix and check if it works? If it helps, I can create a separate pull request for this. I do not think this is related to https://jira.duraspace.org/browse/DS-3108, since Cédric is able to complete the authentication request. I have another idea about DS-3108 which I will post in the comments of that ticket. Best regards, Tom [image: logo] Tom Desair 250-B Suite 3A, Lucius Gordon Drive, West Henrietta, NY 14586 Esperantolaan 4, Heverlee 3001, Belgium www.atmire.com <http://atmire.com/website/?q=services&utm_source=emailfooter&utm_medium=email&utm_campaign=tomdesair> 2016-12-21 23:38 GMT+01:00 Terry Brady <[email protected]>: > The Shibboleth issue is still open. I suspect that you are running into > the same issue with LDAP. > > It would be good to know if anyone on the list can confirm that REST/LDAP > authentication works in DSpace 6. > > Terry > > On Wed, Dec 21, 2016 at 7:45 AM, Devaux Cédric <[email protected]> > wrote: > >> Hello, >> >> I want to use LDAP Authentication with Rest and there is a problem. >> The LDAP authentication ( /login ) seems OK : response 200 and in >> dspace.log : >> *2016-12-21 11:09:52,551 INFO org.dspace.authenticate.LDAPAuthentication >> @ *@*.*::authenticate:type=ldap* >> *2016-12-21 11:09:52,551 INFO org.dspace.eperson.EPersonServiceImpl @ >> *@*.*::update_eperson:eperson_id=39...* >> >> But when I check the authentication (/status) with the JSESSIONID from >> the /login response, "authenticated" is false : >> *<?xml version="1.0" encoding="UTF-8" >> standalone="yes"?><status><apiVersion>6</apiVersion><authenticated>false</authenticated><okay>true</okay><sourceVersion>6.0</sourceVersion></status>* >> >> It's OK with Password Authentication with Rest (but the response to >> /status request is different, without apiVersion and sourceVersion : >> *<?xml version="1.0" encoding="UTF-8" >> standalone="yes"?><status><authenticated>true</authenticated><email>*</email><fullname>*</fullname><okay>true</okay></status> >> )* >> >> I'd like to know if someone has ever successfully used LDAP >> authentication in Rest Api or if it's a bug like with Shibboleth >> Authentication ( https://jira.duraspace.org/browse/DS-2898 , >> https://jira.duraspace.org/browse/DS-3108 ) ? >> >> Regards, >> Cedric >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "DSpace Technical Support" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/dspace-tech. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Terry Brady > Applications Programmer Analyst > Georgetown University Library Information Technology > http://georgetown-university-libraries.github.io/ > <https://www.library.georgetown.edu/lit/code> > 425-298-5498 <(425)%20298-5498> (Seattle, WA) > > -- > You received this message because you are subscribed to the Google Groups > "DSpace Technical Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
