From: Wellaway, I. <I.J...@ex...> - 2012-12-12 10:27:52
|
Thanks Stuart, I did see you article on using a separate dspace.cfg file but I'm not sure if it would work now that dspace have fragmented their cfg files. Instead, I turned off the 'Basic' sword authentication, pointed our SSO at the servicedocument and then used the HTTPServletRequest object passed into the SwordApiEndpoint.java class to request the current authenticated user (request.getRemoteUser). Then this username is passed to our new custom SSO Dspace authentication module. Best regards Ian ------------ Ian Wellaway Senior System Support & Development Officer - Enterprise Applications (Wednesdays only) & Technical Developer, Open Exeter - Infrastructure Systems (Monday-Tuesday, Thursday-Friday) Exeter IT Room 54 Laver Building University of Exeter EX4 4QE UK tel +44 1392 722852 From: LEWIS Stuart [mailto:Stu...@ed...] Sent: 11 December 2012 17:04 To: Wellaway, Ian; 'swo...@li...' Subject: RE: [sword-app-tech] Sword authentication using custom dspace auth module Hi Ian, I think the following should help: - http://blog.stuartlewis.com/2008/05/27/shibboleth-sword-and-dspace-15/ Basically the answer is to point your sword web app's web.xml at a duplicate DSpace configuration file with a different authorisation stack to the one used by your jspui / xmlui webapp. This gets around the issue of shibboleth not being designed for web service environments (such as SWORD). Caveat: I'm not sure how this works with more recent versions of DSpace that use the dspace/config/modules/authentication.cfg file to provide the authorisation stack configuration. Thanks, Stuart From: Wellaway, Ian [mailto:I.J...@ex...] Sent: 11 December 2012 13:40 To: 'swo...@li...' Subject: [sword-app-tech] Sword authentication using custom dspace auth module Hi, I've created a new custom SSO authentication module for dspace and added it to the auth stack (it's the only entry in the stack). This works fine with Dspace itself. However, it doesn't work with Swordv2 in that I can't get the service document. It does work if I change back to LDAPHierarchicalAuthentication only, but if I try to use both my new RemoteUser Auth and the LDAPHierAuth in the stack it fails. It also fails no matter what order I use in the stack or if I add extra auth modules (like password). Where it seems to fail is when the SwordAuthenticator tries to call the authenticate method of AuthenticationManager : public boolean authenticates(Context context, String un, String pw) { log.info(LogManager.getHeader(context, "sword_authenticate5", "call authenticate")); int auth = AuthenticationManager.authenticate(context, un, pw, null, null); log.info(LogManager.getHeader(context, "sword_authenticate6", "authenticate="+auth)); if (auth == AuthenticationMethod.SUCCESS) { return true; } return false; } As you can see, I've added two lines of logging code. In my log, I get the INFO sword_authenticate5 but not 6. I also get no logs at all from the RemoteUserAuthentication class which is basically a copy of the LDAPHierarchicalAuthentication class, even if I put a log entry as soon as the code gets there So, any ideas what might be wrong here? Is there something you need to do to make SWORD work with a custom authentication module. To start with, I'm not trying to make SWORD go through SSO, just trying to get it to accept the custom authentication module. Thanks Ian ------------ Ian Wellaway Senior System Support & Development Officer - Enterprise Applications (Wednesdays only) & Technical Developer, Open Exeter - Infrastructure Systems (Monday-Tuesday, Thursday-Friday) Exeter IT Room 54 Laver Building University of Exeter EX4 4QE UK tel +44 1392 722852 |