My guess was "just the /login path" since DSpace will forward any page requiring auth to this path, and since Shib is implemented as stackable auth, it would pick up from there and do its work.
But I haven't seen any examples of this configuration anywhere, and the closest I've seen doesn't line up with this theory:
I think you need to protect /shibboleth-login (or if you use the webapp name in your deployment path, /jspui/shibboleth-login etc).
The Shibboleth code will then kick in when the user visits that URL, which is defined in the loginPageURL method of ShibAuthentication.java. Once authenticated, it bounces the user back to the URL, tomcat does its stuff, the servlet is used, the shib values read, and the user is logged in.
public String loginPageURL(Context context, HttpServletRequest request,
As an aside, just in case anyone is interested, I've just finished developing a Java/Tomcat/DSpace Shibboleth solution that doesn't require the use of mod_shib+Apache. It isn't as mature as mod_shib (for example it doesn't currently cope with encrypted NameIDs), but it seems to work fine, and we're about to roll it out to our production servers.
Is it based on the OIOSAML Servlet Filter, so acts at the Tomcat Filter level rather than as an Apache module. If you don't currently front your tomcat instance with apache, it can simplify Shibboleth installation. http://www.ohloh.net/p/oiosaml
IT Innovations Analyst and Developer
Te Tumu Herenga The University of Auckland Library
Auckland Mail Centre, Private Bag 92019, Auckland 1142, New Zealand
Ph: 64 9 373-7599 x81928http://www.library.auckland.ac.nz/