[shib_auth] Drupal Shibboleth Module -- General Question

[Kristof Bajnok]

Hi Paul,

there is a (not-so-active) mailing list for shib_auth. If you write
there, others could benefit from the conversation.

Answers inline:

On 23/05/12 23:06, Paul Bramscher wrote:
> Greetings--
> 
> We're running Drupal here at the University of Minnesota Libraries and
> our entire campus is in the process of converting to the Shibboleth
> authentication schema.  We've begun using the Drupal Shibboleth module,
> but have run into a strange issue.  Our site runs both Drupal and
> non-Drupal applications, HTTP and HTTPS.
> 
> I believe the use-case works like this:
> 
> 1. User hits a Shibboleth-protected resource in Drupal and is prompted
> to login to the Shibboleth Identity Provider.  This works fine.
> 2. User navigates around in Drupal, but might go to a non-SSL or
> non-Drupal location on the server.  They lose their Shibboleth session ID.
> 3. Now perhaps they come back to the Drupal context and their Shib
> Session ID changes.  They are now no-longer logged in to Drupal, but
> they do have a (new) Shibboleth session.
> 
> My question is this--
> 
> Internally, in the Drupal Shib module, does it rely on the Shib session
> ID to maintain user state within Drupal, or does it still use its own
> internal Drupal session ID?  Because it is quite possible to have a
> Shibboleth session cookie which is just temporarily not readable by a
> Shib identity provider while the user navigates over non-SSL, and then
> the Shib session ID apparently changes the next time they come back.

Yes, we rely on Shibboleth SP session ID, if the infamous "Destroy
Drupal session if..." switch is on. A couple of features depend on this
switch, especially Single Logout support.

> Currently, our main Drupal programmer has had to force the entire site
> into SSL in order to avoid this possible scenario.  Is this probably our
> best option?  We have a fairly high-volume site, and this will
> undoubtedly use up more system resources.

There is the handlerSSL parameter for the Shibboleth SP Sessions
element, and by setting this to "false" you can propagate the session
for plain HTTP requests as well.

On the other hand, particularly for supporting stateless Shibboleth
clustering, for a long time, I've been planning to implement a solution
which would probably solve your problem as well without
handlerSSL="false". Unfortunately I still haven't had enough time to
implement it.

Best regards,
Kristof