[shib_auth] Shibboleth Protection Path

[Nate Klingenstein]

Kristof,

> Correcting myself: role assignment is only run if the Identity Provider
> field is set, what means that the request is directed through the Shib
> SP ("require shibboleth") .

As you vaguely alluded to, if roles are sticky, then this requirement 
doesn't hold, right?

I might think that updating roles during the session creation process 
might be good enough for most deployments.  That might make another good 
configuration option, though I understand the need to be wary about 
introducing too many parameters.

> And also shib_auth consumes some CPU cycles when it detects the
> Shibboleth headers.

We didn't run any benchmarking tests and we're not looking at a 
deployment that will be under so much load that this(or mod_shib) is 
likely to cause enough overhead to be a problem, so we're not likely to 
do any benchmarking immediately.  We may do it later, and if so, I'll 
definitely update you.  I just want to reduce the amount of processing 
where possible and anticipate working on some deployments where this 
would become an issue.

Separately, we ran into problems with the strict email validation(many 
IdP's don't/won't release email addresses, forcing the SP/Drupal to 
populate email address in the database with e.g. a principal name) and 
the check to ensure that the uname variable matches the current 
authenticated principal in Drupal even if strict session checking is 
disabled.

In general, we recommend as part of the Shibboleth project that 
Shibboleth sessions not be replicated/clustered if it can be 
avoided(because the application's session cookie is being replicated 
already, in this case SESS).  It's difficult to design a module for all 
scenarios, and I can understand apprehension about making it easy for 
deployers to introduce security vulnerabilities, but I'd love to see a 
little engineering work done on the Drupal module to make it easier to 
use shib_auth without a Shibboleth session present and only the login 
directory protected, with the proper caveats in place.  I think that's 
going to be a very common deployment paradigm for large Drupal sites 
leveraging your work.

Thanks for your work on the module,
Nate.