<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
On 28.10.2013, at 12:48, Kristof Bajnok <<a href="mailto:bajnokk@niif.hu">bajnokk@niif.hu</a>> wrote:<br>
<div><br class="Apple-interchange-newline">
<blockquote type="cite">You don't have lazy sessions and Shib authorisation at a time, no.<br>
</blockquote>
<div><br>
</div>
<div>Actually, you kind of do. Just adding arbitrary ‘require’ statements in a sub-location that inerits lazy sessions works perfectly well.</div>
<div>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.</div>
<div><br>
</div>
<div></div>
<blockquote type="cite">
<div><br>
</div>
<div>
<blockquote type="cite">Second: in a SAML Federation this simply pollutes the users list in<br>
Drupal with unnecessary entries that never should be there in the<br>
first place. A secure system should be as simple as possible and a<br>
user that should not get access should get no access at all.<br>
Unnecessary user entries escalate the possibility that some human<br>
error results in security breach.<br>
</blockquote>
<br>
Agreed.<br>
One of the use cases arised so far was to support only pre-created<br>
users. It may not fit to yours: <a href="https://drupal.org/node/729388">https://drupal.org/node/729388</a> .</div>
</blockquote>
<div><br>
</div>
That does not quite match us, but there was a link to another feature request that seems closer to us - I added my +1:</div>
<div><br>
</div>
<div><a href="https://drupal.org/node/1724166#comment-8007319">https://drupal.org/node/1724166#comment-8007319</a></div>
<div><br>
</div>
<div>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.<br>
<br>
<blockquote type="cite">Third: creating another role that implements ‘logged in user’ and<br>
<blockquote type="cite">then applying that role to all existing (noh-shib) users and<br>
stripping current rolel of all privileges is just extra manual work<br>
that is not neccessary.<br>
</blockquote>
<br>
Anybody with a valid Shibboleth session is an authenticated user. You<br>
shouldn't mix authentication with authorisation.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>To make a more earthly example, consider a campus with central security codes.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<blockquote type="cite">Try it with force protecting the shib_login/node Drupal page (whatever<br>
this is in your webserver) and disallow session expiry. If you can get<br>
through the mod_rewrite mess, it may work in theory. It's not a<br>
supported setup now, but I'm interested in your results.<br>
</blockquote>
</div>
<br>
<div>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.</div>
<div><br>
</div>
<div>So it does work for first-seen users, but not for revisiting unauthorized users.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Best,</div>
<div>Laas Toom</div>
</body>
</html>