[shib_auth] Authorization

[Laas Toom]

On 28.10.2013, at 12:48, Kristof Bajnok <bajnokk at niif.hu<mailto:bajnokk at niif.hu>> wrote:

You don't have lazy sessions and Shib authorisation at a time, no.

Actually, you kind of do. Just adding arbitrary ‘require’ statements in a sub-location that inerits lazy sessions works perfectly well.
Only problem is that you can’t authorize the ‘lazy area’ of the app. That is why I would like shib_auth not to authorize users from lazy session, only from that single strong session entry point.


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.

Agreed.
One of the use cases arised so far was to support only pre-created
users. It may not fit to yours: https://drupal.org/node/729388 .

That does not quite match us, but there was a link to another feature request that seems closer to us - I added my +1:

https://drupal.org/node/1724166#comment-8007319

If that feature request could be implemented, it could solve my problem too, as I might be able to combine the two attributes into one and use that as the role mapping basis.

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.

Anybody with a valid Shibboleth session is an authenticated user. You
shouldn't mix authentication with authorisation.

I’m not mixing authn and authz. I’m trying to draw a line between realms. One is the federation that can create valid Shibboleth sessions for all users. The other is the Drupal application that should not create any user account (thus not log in) unless the user is at the same time authorized to get access.

To make a more earthly example, consider a campus with central security codes.

The current shib_auth implementation works like this: to enter a building I punch in my central PIN code and I get access to the hallway. Then I’m given a keycard which may or may not open some of the doors in the building. And, btw, the PIN readers are installed at every door and window of the building.

A more secure system would have the PIN readers only at the few main doors (the others being locked) and would not even let me enter the building unless I’m entitled to access one of the rooms in the building. That way any administrator knows that if I’m in the building, I must have some reason to be there and I must have come through one of the main doors. And if there is a problem, there are only so many places to look at.

Try it with force protecting the shib_login/node Drupal page (whatever
this is in your webserver) and disallow session expiry. If you can get
through the mod_rewrite mess, it may work in theory. It's not a
supported setup now, but I'm interested in your results.

It almost does work. I’ve protected the "/shib_*” locations and it efectively denies creating new users when not authorized, but for existing users that already have Drupal entries, but have lost their affiliation with the university (say, graduated), the /shib_login/intro page is denied, but they are still automatically logged in on any other page.

So it does work for first-seen users, but not for revisiting unauthorized users.



Best,
Laas Toom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.niif.hu/pipermail/shib_auth/attachments/20131028/19b8607d/attachment.html>