I've made a test with DSpaceAuthenticationProvider.java provide by Tom ( https://github.com/milieuinfo/dspace54-atmire/blob/ontwikkel/dspace/modules/rest/src/main/java/org/dspace/rest/authentication/DSpaceAuthenticationProvider.java<https://github.com/milieuinfo/dspace54-atmire/blob/ontwikkel/dspace/modules/rest/src/main/java/org/dspace/rest/authentication/DSpaceAuthenticationProvider.java#L65> ) and it's OK :
When I check the authentication (/status) with the JSESSIONID from the /login response, "authenticated" is now true : <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <status><authenticated>true</authenticated><email>*@*.*</email><fullname>Cedric Devaux</fullname><okay>true</okay></status> (The response to /status request is now similar to Password Authentication : without apiVersion and sourceVersion ) Thanks for this solution. Regards, Cedric ________________________________ De : dspace-tech@googlegroups.com [mailto:dspace-tech@googlegroups.com] De la part de Tom Desair Envoyé : jeudi 22 décembre 2016 09:41 À : Terry Brady Cc : Devaux Cédric; dspace-tech@googlegroups.com Objet : Re: [dspace-tech] DSpace 6.0 : problem with LDAP authentication in REST API 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 [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> -- 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 dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
