[shib_auth] Authorization

[Laas Toom]

On 28.10.2013, at 9:50, Kristof Bajnok <bajnokk at niif.hu> wrote:

> On 2013-10-28 08:41, Laas Toom wrote:
>> I’m in the process of protecting a Drupal app with Shibboleth and the
>> shib_auth module.
>> 
>> Our requirement is that the application must remain publicly visible
>> to the world, but logged in users get write access. The problem is
>> that not all Shibboleth users must get access and I can’t really
>> figure out how to apply authorization when Shibboleth is configured
>> to use lazy sessions and shib_auth automatically grants ‘logged in
>> user’ role to all users.
> 
> IMHO you're not forced to give write access to Authenticated Users.
> 
>> I know I can map Shibboleth attributes to roles, but that doesn’t
>> override the automatic login.
> 
> What problem does it make when authenticated users automatically get
> logged into Drupal? You should use proper role mapping and permission
> control (authorization).

First of all: attribute to roles mapping is one-to-many only, but my requirement is to create AND condition between two attributes that must both have required values for the authorization to succeed. Shibboleth alreany has that covered (and even more advanced setups are possible). Why not support that?

Second: in a SAML Federation this simply pollutes the users list in Drupal with unnecessary entries that never should be there in the first place.
A secure system should be as simple as possible and a user that should not get access should get no access at all. Unnecessary user entries escalate the possibility that some human error results in security breach.

Third: creating another role that implements ‘logged in user’ and then applying that role to all existing (noh-shib) users and stripping current rolel of all privileges is just extra manual work that is not neccessary.


>> Is there a reason, why the shib_auth is set up so that lazy sessions
>> are required? Wouldn’t it be better to make it more like password
>> authentication where a single point of entry is protected, where the
>> user session is created, not on every request.
> 
> It is a design decision. It allows the module to handle Single Logout
> and session expiry.

SLO and session expiry is configuration-switchable anyway, so that could be seen as added value, not core feature.

Therefore shib_auth should use strong sessions and a single point of entry for authn/authz and, if one wants that, lazy sessions in application root for SLO and session expiry detection.

Everything would still work as it does now, but with added bonus of Shibboleht-based authorization.


Best regards,
Laas Toom