Hi,
 
I have integrated (one of) our DSpace instances (running v1.4.2) with our (home grown) portal authentication by creating an implicit authentication class that checks for our portal authentication cookies, and if they are there (and valid), it creates a DSpace authentication context for the user (creating an ePerson record on the fly if necessary) - it works pretty well, but I have 2 problems I can't get to the bottom of and wondered if anyone had any pointers etc.
 
Problem 1:
=======
If a user logs in to our portal and then accesses DSpace and clicks "My DSpace", the authentication class kicks in and they end up at their My DSpace page . . . Fine.
 
The bitstreams in DSpace are protected by a READ policy that only allows members of the group STIR_USERS to get access (and all new portal authenticated ePersons are automatically added to this group) - if a user has a DSpace authentication context in place (i.e. it says "Logged in as" at the top left), the user can access protected bitstreams no problem. Fine.
 
However, if a user logs on to our portal, and then accesses DSpace (so not actually logged on to DSpace at this point but portal auth cookies in place), the first time they try to access a bitstream they get the page "Authorisation Required" - however, when presented with the "Authorisation Required" page, it appears that they have been authenticated because the "logged in as" message has appeared, and hitting refresh brings up the required bitstream (and subsequent access to bitstreams works fine). So it looks like the authentication class is being correctly called when they try to access the bitstream, and the authentication context is being set up, but for some reason I can't fathom, they don't get access to the bitstream but instead get redirected to the Authorisation Required screen . . .
 
The logs give me this:
 
2008-03-28 16:09:12,594 INFO  org.dspace.eperson.StirPortalAuthentication @ anonymous:session_id=1C92899D8684656C55C3EE88796A86CF:ip_addr=139.153.92.71:login:type=StirPortalAuthentication
2008-03-28 16:09:12,594 INFO  org.dspace.app.webui.util.Authenticate @ mw6@stir.ac.uk:session_id=1C92899D8684656C55C3EE88796A86CF:ip_addr=139.153.92.71:login:type=implicit
2008-03-28 16:09:12,594 INFO  org.dspace.app.webui.servlet.DSpaceServlet @ mw6@stir.ac.uk:session_id=1C92899D8684656C55C3EE88796A86CF:ip_addr=139.153.92.71:authorize_error:org.dspace.authorize.AuthorizeException: Authorization denied for action READ on BITSTREAM:232 by user 0
 
- which seems to suggest some kind of problem - it recognises me as mw6@stir.ac.uk but describes me as "user 0". If I hit refresh, the item appears and the log shows the next line as:
 
2008-03-28 16:09:16,605 INFO  org.dspace.app.webui.servlet.BitstreamServlet @ mw6@stir.ac.uk:session_id=1C92899D8684656C55C3EE88796A86CF:ip_addr=139.153.92.71:view_bitstream:bitstream_id=232
 
 
Has anyone else ever seen this kind of behaviour with an implicit authentication class? Anyone have any idea why this may be happening? Am I doing something stupid with permissions? Any ideas where in the code I can dig about to learn more about what is happening, or any code hack suggestions to make this work the way I think it should?
 
Problem 2:
=======
Portal authentication is part of an authentication stack with "normal" authentication below (so external users can create accounts if needs be) - if a user who has NOT logged on to our portal attempts to access a bitstream the implicit authentication fails (correctly), and they are routed to the normal DSpace logon page - I've added a link to this page for our local users which goes to our portal logon page with a redirect back to the DSpace homepage - I would like, however, for this redirect to take the user back to whatever page/bitstream they were trying to access.
 
So, is there anyway to pick up the URL of the page they were trying to access (where the authentication was required) from within the logon JSP page so that I can embed this in the link to our portal logon page?
 
Another possibility is to remove the "normal" authentication class altogether (understanding that this means no external users can use this instance of DSpace) and have the portal authentication class automatically route them to our portal logon (along with an appropriate redirection URL back to DSpace) if the implicit authentication fails - is this doable? If so, anyone got any pointers on how best to achieve it?
 
Thanks in advance for any suggestions/pointers anyone may have (and to anyone else who bothered to read to the end of this rather wordy request for help!).
 
Cheers,
 
Mike

Michael White
eLearning Developer

Centre for eLearning Development (CeLD)
S7, The Library

University of Stirling

Stirling SCOTLAND

FK9 4LA

Email: michael.white@stir.ac.uk
Tel: +44 (0) 1786 466877

Fax: +44 (0) 1786 466880

http://www.is.stir.ac.uk/celd/

 

--

The University of Stirling (a charity registered in Scotland, number SCO11159) is a university established in Scotland by charter at Stirling, FK9 4LA. Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not disclose, copy or deliver this message to anyone and any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind.