[shib_auth] Shibboleth Protection Path

[Kristof Bajnok]

Hi Nate,

On 16/04/12 19:52, Nate Klingenstein wrote:
>> 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?

Right, sticky roles are assigned by the user module.

> 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.

If I'm not mistaken, for non-sticky roles, the $user object needs to be
updated on every request. It'd be possible to place an object to the
session and do the actual role assignment based on the cached roles.
(For those who read the code: this should not be confused with the
current 'rolecache' things, that only cache the role names.) This would
indeed eliminate the need for the headers, which the roles are based on.

Anyway, I've added this idea to the feature request about supporting
non-shared SP sessions. (https://drupal.org/node/1272318)

> 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) 

If the 'user-defined' email is not an option, then would it be useful to
register the user with fake email information? I filed a feature request
about that, too (https://drupal.org/node/1295596), though haven't gotten
to work on this, yet.

> and
> the check to ensure that the uname variable matches the current
> authenticated principal in Drupal even if strict session checking is
> disabled.

Hm, is this something that came up with non-shared clustering? I can't
think any other use case where the Drupal user and the Shibboleth
principal should be different on purpose. (And with clustering, only
null principals should be allowed.)

> 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.

Okay, I hope that I can work on this area in the next couple of days.
(This is not a commitment, unfortunately, I can spend far less time on
shib_auth than what would be necessary.)

Kristof