Skip to Content.
Sympa Menu

shibboleth-dev - RE: Negated require rules?

Subject: Shibboleth Developers

List archive

RE: Negated require rules?


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: Negated require rules?
  • Date: Fri, 26 Oct 2007 13:18:26 -0400
  • Organization: The Ohio State University

> As you've noted, blacklisting based on non-identity attributes is not
> so useful. At one point, we thought that any attribute might be
> blacklisted, and while it doesn't hurt to add a group membership
> (e.g.) to a blacklist, it may not always have the desired effect.

My concern is mainly that it introduces some pretty tricky semantics that
may lead to a lot of confusion, not to mention assumptions about how
attributes are managed, that may be bad.

It also assumes that the absence of an attribute is not caused by simple
technical failures. It seems pretty wrong to me that you would deny somebody
access in the normal case but allow it if their attribute authority was
down. There's no way for me to carve out that exception, it would destroy
the entire design.

> On the other hand, there's no difference between identity and
> non-identity attributes as far as the actual mechanism is concerned,
> so the latter will automatically be supported.

In my case it turns out that it's pretty different, and I did see that there
was value in blacklisting based on identity attributes. When I enforce a
require user rule, it's very reasonable for me to say that the rule can only
be satisfied if REMOTE_USER actually has a value. Even if the rule is
"anybody but Tom", I can't consider the rule met if there's no data there
for me to examine.

I can't do that with ordinary attributes because the absence of the
attribute doesn't mean anything's wrong, it just means it had no values.
Identity attributes may be present or not, but they always have a value for
each user, so not having that value available is always treatable as an
exceptional condition.

Anyway, I think I independently reached the conclusion that negation was
reasonable for anything where I could refuse to accept the rule if the input
data was missing, and not reasonable otherwise.

The htaccess processor is now rewritten to support that, and does a better
job of stopping when a rule fails (if ShibRequireAll is on). Before it used
to examine every rule no matter what.

-- Scott





Archive powered by MHonArc 2.6.16.

Top of Page