Lazy sessions and authorization (Drupal)

[Laas Toom]

On 25.10.2013, at 15:36, Peter Schober <peter.schober at univie.ac.at> wrote:

> * Laas Toom <Laas.Toom at ut.ee> [2013-10-25 14:17]:
>> Is there a way to apply authorization when using lazy sessions?
> 
> Not with httpd directives, no.

But with Shibboleth XML directives this is possible? Could you point me to docs or something?

> 
>> This might sound ridiculous, but I need to protect a Drupal site
>> based on two attributes:
>> 
>>    ShibRequireAll On
>>    require unscoped-affiliation member
>>    require homeOrganization example.org
> 
> This seems like a weird/broken way of writing just:
> 
>  require affiliation member at example.org
> 
> Also the latter will prevent any unauthorized IdP from issuing member
> in the scope "example.org" (with the Shib SP's default config), while
> the former (your example) will not, unless you add custom rules to
> your SP's attribute-policy.xml
> If the IdP cannot send the latter format it should be fixed.

We have a Hub-and-Spoke federation so the SP filters by Hub’s metadata that will never match the actual scope.
At the same time the Hub will itself guarantee the homeOrganization to be valid so I can trust that.

Of course I could try to persuade the Hub managers to apply filters to scoped attributes so that SPs could just blindly trust those, but that would certainly take some time, if at all accepted.

But that aside, even with ‘affiliation member at example.org’ I would still need to have a way to apply this requirement on lazy sessions.

> 
>> What I have now is lazy sessions on / and then use:
>> 
>>    <LocationMatch “/drupal/shib_”>
>>       # above authorization requirements
>>    </LocationMatch>
> 
> Unrelated but note that this directive will also match
> /foo/bar/drupal/shib_whatever/baz/baaz/quax
> Probably unlikely to create problems here but Always Anchor Your
> Regular Expressions.

Yeah, that was just me retyping from memory. Actual config is anchored. :-)

> 
>> This works to a degree - first-time users are effectively denied
>> access, because Shibboleth blocks shib_auth from creating user
>> accounts.
>> 
>> BUT, when an existing user looses privileges (say graduates and
>> looses member affiliation) the user first gets a 403 error when
>> first returning from IdP, but if she then manually returns to the
>> root of the application, suddenly shib_auth recognizes the username
>> and grants access, because Shibboleth fills in the attributes and
>> does not authorize them.
> 
> I'm not sure I understand. /drupal/shib_auth (or whatever) should be
> the place where the Drupal application session is being created, based
> on attributes supplied by the local SP, no? Then I shouldn't be able
> to ever successfully create a session if access to /drupal/shib_auth
> /requires/ attributes I don't have? But I'm not aware of the internal
> workings of the shib_auth module, I haven't looked at it in years.

I’m not familiar with inner workings of Drupal, but skimming through the shib_auth source I gather that the module tries to establish user session from Shibboleth ENV every time Drupal initializes this module on every request, regardless of the URL.
Verified by experiment: do a manual login via /Shibboleth.sso/Login and only then open /drupal for the first time - logged in successfully.

I.e. there really is no single entry point to protect with forced session.


> Note that at https://drupal.org/project/shib_auth they ask that
> questions and support requests should be sent to their mailing list,
> so I'd try that.

I will try that too, but the documentation also requires me to enable ShibUseHeaders which made me a bit wary of their advice and hoped somebody here has some experience.


Best,
Laas Toom