Lazy sessions and authorization (Drupal)

[Cantor, Scott]

On 11/4/13, 3:31 PM, "Laas Toom" <Laas.Toom at ut.ee> wrote:

>Basically, lets forget Drupal for the moment and consider a simple PHP
>script that relies on HTTP Basic Auth with .htpasswd specifically for
>this page. Anybody gets to view the page, but POSTing comments is allowed
>only if REMOTE_USER is set.

But you don't implement that by using a single resource and ruleset for
both, you have separate resources (or limit the rules to POST) for the
commenting. So it's not one script, it's logically two.

>In such a setup there are two groups of users: anonymous users and
>authorized users.

No, there are still three, add "authenticated users not in your authorized
users list". What would you do to handle that case with Basic-Auth? You
can't tell it not to set REMOTE_USER "if they're not in the user list",
but that's conceptually what you're suggesting below.

If you say require foo bar, you're going to block everyone but foo and
bar, same outcome. The way you fix that is by limiting the rule to apply
to only the act of commenting, and then you block both anonymous users and
anybody not in the policy.

>Now, if I replace the Basic Auth with Shibboleth, the first group is
>split into two: really unauthenticated users and those valid SSO users
>that should not get to POST comments. The third group is the same authz
>users as before who get POST access.

See above, you already have that situation with Basic Auth.

>Without modifying the application, I don¹t see how I could retain the
>above functinality.

If you implement the application in a way that hides the difference in
action from Apache, then you must change the application. That's true with
either authentication method. So the key is that you may be encountering a
problem with Drupal, but you won't be able to fix that with Shibboleth and
it would be highly inappropriate to mix "authorized" with "data exported".
The data being exported has nothing to do with authorization, and in fact
what you suggest can't be done. They don't happen in the right order.

>I named it bad. What I meant was ³Do not set ENV variables if not
>authorized² - essentially kicking the second group into being
>unauthenticated as far as this app is concerned.

The hook in which the export happens runs first in Apache. It's part of
authentication, not part of authorization.

-- Scott