Re: [Dspace-tech] Implicit authentication issues . . .
Hi Simon,
You wrote:
> It might be worthwhile, at least as a workaround, to change the code
> to attempt an implicit auth at the beginning of the request rather
> than waiting for it to fail at the end. Something like this:
>
> In DSpaceServlet.processRequest(), after the lines:
>
>// Obtain a context - either create one, or get the one created by
>// an authentication filter
>context = UIUtil.obtainContext(request);
>
> insert (copied from Authenticate.java):
>
> if (AuthenticationManager.authenticateImplicit(context, null,
null,
> null, request) == AuthenticationMethod.SUCCESS)
> {
> Authenticate.loggedIn(context, request,
context.getCurrentUser());
> log.info(LogManager.getHeader(context, "login",
"type=implicit"));
> }
>
> Which should, if my thinking is correct, set up the implicitly
> authenticated user in the context before any of the actual request is
> processed.
>
> I should stress that I have not tested this and so it may not work,
> but it's a problem we're about to hit here because we're currently
> implementing an auth filter for the university's SSO system. So I
> almost certainly *will* be testing this before the week is out.
Good thinking :-) I've just tried this, and whilst I haven't tested
extensively, it appears to work brilliantly, so thanks a million! I am,
officially, a happy bunny . . . . :-)
Now the last problem I have to solve is to capture and embed the
originally requested URL into the login form so that I can provide a
link to our portal SSO system (along with the original URL) to
authenticate un-authenticated users and then enable our portal to
redirect them back to the original URL - I do recall seeing the original
url being put into a session variable when I was perusing the
authentication code the other day, but if anyone has any pointers that
will save me digging through the code and hacking (fairly) aimlessly for
the rest of the afternoon, they would be more than welcome :-)
Cheers,
Mike
Michael White
eLearning Developer
Centre for eLearning Development (CeLD)
S7, The Library
University of Stirling
Stirling SCOTLAND
FK9 4LA
Email: [EMAIL PROTECTED]
Tel: +44 (0) 1786 466877
Fax: +44 (0) 1786 466880
http://www.is.stir.ac.uk/celd/
Re: [Dspace-tech] Implicit authentication issues . . .
On 21 Apr 2008, at 16:53, Michael White wrote:
> Hi,
>
> Unfortunately I've been sidetracked with other tasks, so only just
> coming back to look at my implicit authentication problems first
> raised
> a couple of weeks ago . . .
>
> Using DSpace v1.4.2. This DSpace is being used as a Learning Object
> repository and all the items in the repository are protected (only
> accessible to Stirling staff and students).
>
> Summary of main problem, when accessing a protected bitstream with the
> token required for implicit authentication in place (a cookie from our
> portal in this case), instead of being authenticated/authorised and
> routed to the requested bitstream, the user is authenticated but then
> routed to "Authorisation Required" page (even though they are now
> authenticated!)
[...]
> I've tried a couple of (fairly random) hacks in various places to try
> and get the request re-routed back to the original URL, but I've had
> no
> joy :-(.
>
> The academic that I've implemented this repository for is doing a demo
> to the University community on May 8th, so I'm obviously very keen to
> try and fix this before then! If there is anyone out there who may be
> able to help, it would be very much appreciated!!
It might be worthwhile, at least as a workaround, to change the code
to attempt an implicit auth at the beginning of the request rather
than waiting for it to fail at the end. Something like this:
In DSpaceServlet.processRequest(), after the lines:
// Obtain a context - either create one, or get the one
created by
// an authentication filter
context = UIUtil.obtainContext(request);
insert (copied from Authenticate.java):
if (AuthenticationManager.authenticateImplicit(context, null,
null,
null, request) == AuthenticationMethod.SUCCESS)
{
Authenticate.loggedIn(context, request,
context.getCurrentUser());
log.info(LogManager.getHeader(context, "login",
"type=implicit"));
}
Which should, if my thinking is correct, set up the implicitly
authenticated user in the context before any of the actual request is
processed.
I should stress that I have not tested this and so it may not work,
but it's a problem we're about to hit here because we're currently
implementing an auth filter for the university's SSO system. So I
almost certainly *will* be testing this before the week is out.
--
Simon Brown <[EMAIL PROTECTED]> - Cambridge University Computing Service
+44 1223 3 34714 - New Museums Site, Pembroke Street, Cambridge CB2 3QH
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Implicit authentication issues . . .
On Mar 28, 2008, at 3:26 PM, Christophe Dupriez wrote: > > But beware: > 1) Standard JNDI Authentication and Realm Login Module does not > implement recursive gathering of groups to which user belongs > (groups of groups are not found) Recursive Groups are bad, I'm sorry to see DSpace supporting this, I did the same mistake in another app I designed and it was a big nightmare once you attempt what your wanting to do. If someone proposed to drop Recursive groups in 2.x I'd be totally on board. The deviation from standard practices and the added complexity are just not worth it. UI's and automation can be written to support creating the appropriate groups and roles without such nesting. > So my question: Does anyone has worked on using standard Tomcat > authentication (JAAS or JNDI) instead of DSpace Authentication > plugins? No, but again, I'd support any attempt to do so. -Mark ~ Mark R. Diggory - DSpace Developer and Systems Manager MIT Libraries, Systems and Technology Services Massachusetts Institute of Technology - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Implicit authentication issues . . .
Hi,
Unfortunately I've been sidetracked with other tasks, so only just
coming back to look at my implicit authentication problems first raised
a couple of weeks ago . . .
Using DSpace v1.4.2. This DSpace is being used as a Learning Object
repository and all the items in the repository are protected (only
accessible to Stirling staff and students).
Summary of main problem, when accessing a protected bitstream with the
token required for implicit authentication in place (a cookie from our
portal in this case), instead of being authenticated/authorised and
routed to the requested bitstream, the user is authenticated but then
routed to "Authorisation Required" page (even though they are now
authenticated!)
This doesn't happen if accessing My DSpace with the required token in
place - user is authenticated and then seamlessly routed to My DSpace.
It's also worth noting that this problem doesn't occur if you use an
explicit authentication method - when the unauthenticated user attempts
to access a protected bitstream, they are correctly routed to the login
page, and then on to the requested bitstream.
I've been digging a little deeper into the code and I think this
behaviour may be caused by a bug - if there is anyone out there using an
implicit authentication method I would be interested to know if you have
this problem as well (i.e. is it a reproducible bug?). If there is
anyone who is more familiar with the authentication flow than I, I could
do with a little help (to confirm whether the problem definitely is a
bug and to help me fix it if possible!) . . .
Jim Rutherford responded to my original posting:
> This sounds a little odd. Try checking the ordering of the
> authorization processes in the two servlets (BitstreamServlet
> and MyDSpaceServlet if my memory serves me correctly).
OK - looking at the code - the reason My DSpace works but the bitstream
access doesn't seems to be because accessing My DSpace invokes the
"RegisteredOnlyFilter" which puts the authentication context in place
before continuing on to MyDSpaceServlet.
The bitstream access is handled by DSpaceServlet using the doDSGet in
BitstreamServlet - when the BitstreamServlet attempts to retrieve the
required item object using Bitstream.retrieve, the retrieve method calls
AuthorizeManager.authorizeAction, which throws an authorizationException
if the user is not authorised (fair enough).
This authorizationException is caught by DSpaceServlet:
--
catch (AuthorizeException ae)
{
/*
* If no user is logged in, we will start authentication,
since if
* they authenticate, they might be allowed to do what they
tried to
* do. If someone IS logged in, and we got this exception,
we know
* they tried to do something they aren't allowed to, so we
display
* an error in that case.
*/
if (context.getCurrentUser() != null ||
Authenticate.startAuthentication(context, request,
response))
{
// FIXME: Log the right info?
// Log the error
log.info(LogManager.getHeader(context,
"authorize_error", ae
.toString()));
JSPManager.showAuthorizeError(request, response, ae);
}
}
--
So, if the user isn't logged in, this will call
Authenticate.startAuthentication in order to authenticate the user.
It is in Authenticate.startAuthentication where I believe the problem
lies - this does different things for implicit and for explicit
authentication:
- for implicit authentication, if authentication is successful, it
simply returns true.
- for explicit authentication, it stores the current request and
redirects to the login page. The login page passes the credentials to
PasswordServlet which, once authentication is complete, resumes the
interrupted request, so we go round the circle again, but this time with
the appropriate user context in place so they get access.
> Looking at the logs, it seems you are challenged to authenticate,
> you are logged in implicitly, but something doesn't quite work
> correctly:
>> 2008-03-28 16:09:12,594 INFO
>> org.dspace.app.webui.servlet.DSpaceServlet @
>>
[EMAIL PROTECTED]: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
> The logging code has your email address, but not your user ID.
> Can you figure out why this is? This really shouldn't be possible,
> and the reason it's failing is because the auth check is using
> your ID, not your email address to do the resource policy lookup.
Looking at the code above this becomes (fairly) obvious - the
authorisation exception is thrown for the unauthenticated user (as
described above), so the catch block calls the authentication code -
Re: [Dspace-tech] Implicit authentication issues . . .
I have the same problem (and users complaints). I am studying the possibility to use server based authentication (Tomcat) to ease SSO implementation and make it more standard based. Anyone has done this? The idea is that using "basic authentication" (which has a "Remember password" option) (and not Form based authentication) + SSO Catalina Valve + JNDI Realm, I could: 1) authenticatie users using LDAP / Active Directory 2) minimize the problem of repeated identification requests for DSpace but also other Tomcat applications (in my case JSPWiki) 3) keep the whole thing standard and simple But beware: 1) Standard JNDI Authentication and Realm Login Module does not implement recursive gathering of groups to which user belongs (groups of groups are not found) 2) I did not succeeded to have an automatic Kerberos login from MS-Windows client computers to Tomcat I therefore choosed to stick to simple LDAP but to use "Basic Authentication" to allow the browser to remember login information. So my question: Does anyone has worked on using standard Tomcat authentication (JAAS or JNDI) instead of DSpace Authentication plugins? Thanks!!! Christophe James Rutherford a écrit : On Fri, Mar 28, 2008 at 04:27:41PM +, Michael White wrote: 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. 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 . . . This sounds a little odd. Try checking the ordering of the authorization processes in the two servlets (BitstreamServlet and MyDSpaceServlet if my memory serves me correctly). Looking at the logs, it seems you are challeneged to authenticate, you are logged in implicitly, but something doesn't quite work correctly: 2008-03-28 16:09:12,594 INFO org.dspace.app.webui.servlet.DSpaceServlet @ [EMAIL PROTECTED]: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 The logging code has your email address, but not your user ID. Can you figure out why this is? This really shouldn't be possible, and the reason it's failing is because the auth check is using your ID, not your email address to do the resource policy lookup. 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. This is not an uncommon request. It is technologically possible to do this by just passing around the request path & parameters from the URL, but DSpace just doesn't do it. I'm not sure about the historical reasons why (beyond simplicity of implementation), but it shouldn't be too much work to include. When I've done this in the past, I just include the requested page as a hidden parameter in the login form and have the processing servlet look for the parameter and use it if appropriate. 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? This probably isn't going to be pleasant for your users because it rips them out of the context of DSpace and puts an extra burden on your portal to do the redirection back. Again, it would be possible, but I think it's probably the wrong approach, and having DSpace take care of the redirection would be for the best (indeed, if you can do
Re: [Dspace-tech] Implicit authentication issues . . .
On Fri, Mar 28, 2008 at 04:27:41PM +, Michael White wrote: > 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. > > > > 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 . . . This sounds a little odd. Try checking the ordering of the authorization processes in the two servlets (BitstreamServlet and MyDSpaceServlet if my memory serves me correctly). Looking at the logs, it seems you are challeneged to authenticate, you are logged in implicitly, but something doesn't quite work correctly: > 2008-03-28 16:09:12,594 INFO org.dspace.app.webui.servlet.DSpaceServlet @ > [EMAIL > PROTECTED]: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 The logging code has your email address, but not your user ID. Can you figure out why this is? This really shouldn't be possible, and the reason it's failing is because the auth check is using your ID, not your email address to do the resource policy lookup. > 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. This is not an uncommon request. It is technologically possible to do this by just passing around the request path & parameters from the URL, but DSpace just doesn't do it. I'm not sure about the historical reasons why (beyond simplicity of implementation), but it shouldn't be too much work to include. When I've done this in the past, I just include the requested page as a hidden parameter in the login form and have the processing servlet look for the parameter and use it if appropriate. > 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? This probably isn't going to be pleasant for your users because it rips them out of the context of DSpace and puts an extra burden on your portal to do the redirection back. Again, it would be possible, but I think it's probably the wrong approach, and having DSpace take care of the redirection would be for the best (indeed, if you can do this in a general way and provide a patch, I'm sure you'd make some friends ;). cheers, Jim -- James Rutherford | Hewlett-Packard Limited registered Office: Research Engineer | Cain Road, HP Labs | Bracknell, Bristol, UK | Berks +44 117 312 7066 | RG12 1HN. [EMAIL PROTECTED] | Registered No: 690597 England The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated you should consider this message and attachments as "HP CONFIDENTIAL". - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinf
