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
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | shib_allow_empty_remote_user.patch | 2.2 KB | JacobSingh |
| #1 | shib_allow_empty_remote_user.patch | 19.55 KB | JacobSingh |
Comments
Comment #1
JacobSingh commentedHere'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.
Comment #2
JacobSingh commentedoops, bad patch gen.
Comment #3
bajnokk commentedThere 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.
Comment #4
bajnokk commentedBased 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.