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 +0000, 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.
<snip/>
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
begin:vcard
fn:Christophe Dupriez
n:Dupriez;Christophe
org:DESTIN inc. SSEB
adr;quoted-printable:;;rue des Palais 44, bo=C3=AEte 1;Bruxelles;;B-1030;Belgique
email;internet:[EMAIL PROTECTED]
title:Informaticien
tel;work:+32/2/216.66.15
tel;fax:+32/2/242.97.25
tel;cell:+32/475.77.62.11
note;quoted-printable:D=C3=A9veloppement de Syst=C3=A8mes de Traitement de l'Information
x-mozilla-html:TRUE
url:http://www.destin.be
version:2.1
end:vcard
-------------------------------------------------------------------------
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/listinfo/dspace-tech
