Hi!
Really great module, thank you for contributing it.

We have two webservers both running shibboleth and apache behind a load balancer. Using affinity cookies, we keep all Shibboleth.sso/* requests on the same web (for a given session), but after authenticating, we'd like the Drupal session to shared (as it is by default).

After some painful debugging, I found this:

if ($_SESSION['shib_auth_username'] != $uname && empty($_SESSION['shib_auth_account_linking'])) {
      /*  See SA-CONTRIB-2009-070
.....
shib_auth_terminate_session();

The net result of this is that someone logs into server A, and a drupal session is created. The first time they hit server B, $uname (which is $_SERVER['REMOTE_USER']) is empty so the session is destroyed.

I threw in a return TRUE there before the terminate and it "fixes" the problem, but probably exposes the SA mentioned.

Oddly, even with that change, server A no longer gets REMOTE_USER anymore. I'm guessing shibboleth on Server B removes the shib cookie which causes this... correct?

Thanks for your help

Comments

JacobSingh’s picture

Version: 6.x-4.0-rc6 » 7.x-4.x-dev
Category: support » feature
Status: Active » Needs review
StatusFileSize
new19.55 KB

Here's a patch which fixes the issue by exposing a setting. The shibboleth docs themselves discourage sharing sessions while clustering and actually encourage you to do what this patch allows (using shib for the login form and then disregarding it from then on). - https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPClustering

By default, the behavior will be unchanged by this patch, but if an advanced user wants to disable the strict username checking they can.

JacobSingh’s picture

StatusFileSize
new2.2 KB

oops, bad patch gen.

bajnokk’s picture

Title: When using in a multi-server environment, REMOTE_USER is not present on other server and causes session to terminate » Support clustering without shared Shibboleth SP
Assigned: Unassigned » bajnokk

There are a couple of implications: no SLO, problems with dynamic roles, no session expiration, just off the top of my head. However, I think it's a valid use-case, I just need some more time thinking about it. And it also needs proper documentation.

bajnokk’s picture

Status: Needs review » Needs work

Based on a mailing list post, I begin think that it would be possible to implement a dynamic role handling that could work even without an SP session: if the roles were saved to $_SESSION and the role assignment was based on that 'cache'. At the cost of sacrificing 'instant' role changes, which isn't a terribly useful thing, I think.

For supporting SLO, the only way would be to implement some handling of the Shibboleth Notify mechanism. That's hard work in itself.