tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Weaver <>
Subject Container-based authentication and Shibboleth SSO - issue with redirecting login to Shibboleth after session timeout
Date Wed, 16 Jan 2008 19:02:51 GMT

We're having a timeout issue (probably configuration) with Tomcat 5.5.25 
and Shibboleth 1.3f ( ).

The environment is a dev server setup such that the Shibboleth SP is 
integrated with Apache 2.0.52 via mod_shib which is in turn using Tomcat 
(via AJP/JK). Bedework (event calendar) is using Tomcat's built-in authN 
which has been configured to use Shibboleth for authN via the method 
described at: (Bedework 
uses container-based authentication as defined by the Java servlet 
specification. There is no authentication code within Bedework.)

The issue is that when user authenticates to Bedework (via Shibboleth) 
and leaves their browser open for a long time (over the weekend), 
instead of getting the Shibboleth login screen when they return and 
attempt to access a page in Bedework that requires authN, the user gets 
the grey Tomcat (default) login screen which won't let them login 
(because authN is only allowed via the Shibboleth SSO). If the user 
closes the browser (or clears cache/cookies/authenticated sessions) and 
tries the page again, they get the Shibboleth login (as we intended them 
to get).

Below are (hopefully the) relevant Tomcat and Shibboleth SP config 
settings on the dev server that displayed this issue. Do any of these 
look suspicious/wrong? Sent this to the Shibboleth and Bedework user 
mailing list as well as our local Shib guy, and collectively they think 
is not Shib or Bedework but is something with the Tomcat config. Mike 
Douglass (lead Bedework developer) said "My guess is you might need to 
disable servlet container login processing and ensure that shibboleth 
will always catch unauthenticated sessions and do its thing. It's also 
possible there are hooks in tomcat to redirect login processing to 
something like shibboleth." Mattias Amnefelt (another Bedework user) 
said "If you could try using the request dumper valve to see if you 
actually have REMOTE_USER set that would help the debugging. If it's set 
when the request comes to tomcat then it's definitely not a shibboleth 

I noticed also that two of the web.xml's for the webapps in Bedework 
define login and (login) error pages for form auth-method, and another 
is configured for basic auth-method. I could possibly override those 
form configs in our Bedework repackaging build to point at Shibboleth SP 
login paths, but if there is an easy way to both get the session 
timeouts and maybe the login URL redirect set correctly in local tomcat 
config (tomcat/conf/) maybe that would be better.

If you have any ideas, please let me know.

Thanks in advance!

Gary Weaver
Internet Framework Services
Office of Information Technology
Duke University



                See Wiki for details:
                        cacheTimeout - how long before expired sessions 
are purged from the cache
                        AATimeout - how long to wait for an AA to respond
                        AAConnectTimeout - how long to wait while 
connecting to an AA
                        defaultLifetime - if attributes come back 
without guidance, how long should they last?
                        strictValidity - if we have expired attrs, and 
can't get new ones, keep using them?
                        propagateErrors - suppress errors while getting 
attrs or let user see them?
                        retryInterval - if propagateErrors is false and 
query fails, how long to wait before trying again
                Only one session cache can be defined.

<MemorySessionCache cleanupInterval="300" cacheTimeout="3600" 
AATimeout="30" AAConnectTimeout="15" defaultLifetime="1800" 
retryInterval="300" ...
(under Applications)
<Sessions lifetime="7200" timeout="3600" ...

tomcat config:

      <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
             allRolesMode="authOnly" />

(session timeout in minutes)
tomcat/conf/web.xml: <session-timeout>30</session-timeout>

(Bedework) webapp configs:

webapps/ucal/WEB-INF/web.xml:  <login-config>
webapps/ucal/WEB-INF/web.xml:    <auth-method>FORM</auth-method>
webapps/ucal/WEB-INF/web.xml:    <realm-name>demo</realm-name>
webapps/ucal/WEB-INF/web.xml:    <form-login-config>
webapps/ucal/WEB-INF/web.xml:    </form-login-config>
webapps/ucal/WEB-INF/web.xml:  </login-config>
webapps/caladmin/WEB-INF/web.xml:  <login-config>
webapps/caladmin/WEB-INF/web.xml:    <auth-method>FORM</auth-method>
webapps/caladmin/WEB-INF/web.xml:    <realm-name>demo</realm-name>
webapps/caladmin/WEB-INF/web.xml:    <form-login-config>
webapps/caladmin/WEB-INF/web.xml:    </form-login-config>
webapps/caladmin/WEB-INF/web.xml:  </login-config>
webapps/ucaldav/WEB-INF/web.xml:  <login-config>
webapps/ucaldav/WEB-INF/web.xml:    <auth-method>BASIC</auth-method>
webapps/ucaldav/WEB-INF/web.xml:    <realm-name>demo</realm-name>
webapps/ucaldav/WEB-INF/web.xml:  </login-config>

(Bedework) webapp session timeouts minutes):
webapps/cal/WEB-INF/web.xml:    <session-timeout>30</session-timeout>
webapps/caladmin/WEB-INF/web.xml:    <session-timeout>30</session-timeout>
webapps/pubcaldav/WEB-INF/web.xml:    <session-timeout>1</session-timeout>
webapps/soedept/WEB-INF/web.xml:    <session-timeout>30</session-timeout>
webapps/ucal/WEB-INF/web.xml:    <session-timeout>30</session-timeout>
webapps/ucaldav/WEB-INF/web.xml:    <session-timeout>1</session-timeout>

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message