Negating access control rules not working

Closing after release.

http://svn.middleware.georgetown.edu/view/cpp-sp?view=rev&revision=3364

This fixes the negation support that was intended to work. You're welcome of course to take the broader discussion to the mailing list.

The key thing to understand is that negation rules depend on an assumption of complete data. The rules that support negation all have (or at least now have) explicit checks that the data is present, and they're singly-valued, so the presence of the data implies completeness. That's what's missing from the generic rules.

The negation in the other rules is definitely wrong, it's denying access even when there's no match (so it's in the safe but useless direction).

The intention of the negated rules was to negate the entire base expression, so if the usual meaning is "must be A or B or C", the negation was supposed to be "must be not A and not B and not C".

The fix is to reverse the default outcome from false to true so that a match flips the result back to false.

The fact that you can do this in the other plugin doesn't make it a good idea. They should NOT do this. It's a bad idea, for the reasons I stated. Denial ACLs are generally seen as a very nasty problem for infrastructure to deal with. I expect I'll be covering this ground in the FedApp material MACE will be developing, it's definitely something people need to understand.

I think it may be possible to do something like the latter suggestion for other reasons, but I'm feature-frozen for 2.4, so it's not going in now. You can file a request for that going forward separately.

For now, they might want to just create "stubbed" references in shibboleth2.xml to locally maintained policies for various aggregates of content and just have the owner create "allow anything" policies until they need more. That's not too much overhead, if at all.

The thing is this: One of our universities wants to create a rule that would allow only users where affiliation=staff. However, they have users that have a multi-valued affilition like affiliation=staff;student. They want to ensure that such users are denied access. In XML Access Control terms this would be equivalent to:
–
<Path name="#PATH_TO_PROTECT#"
authType="shibboleth" requireSession="true">
<AccessControl>
<AND>
<Rule require="affiliation">staff</Rule>
<NOT>
<Rule require="affiliation">student</Rule>
</NOT>
<OR>
<Rule require="homeOrganization">ethz.ch</Rule>
<Rule require="homeOrganization">uzh.ch</Rule>
</OR>
</AND>
</AccessControl>
</Path>
–
This works as they would expect it.

Another issue (not directly related to this bug) is that they want to have a solution that works like in a .htaccess file so that sub-site administrators can create their own rules of this kind without touching the shibboleth2.xml config. I know that XML Access Control can be externalized (or was it the RequestMap?) in a separate file. However, as far as I know, the link to this external file still has to be added to shibboleth2.xml, which makes it unusable for them. Would it be possible to have an Apache directive like?

require AccessControl /path/to/XMLAccessControl.xml