SV: Attribute Filter policy. Where am I going wrong?

[Rod Widdowson]

TL;DR I've entered IDP-782 and aim to get this done in V3.2

> If Rod wants to shoot me for suggesting that, he can.

It makes a lot of sense to me.  Also it obvious has caused confusion so
let's fix it.

> it was more because that code is complex and he won't want to change it
and rightly so.

So long as I can test it I'll not demur.  The fragility of the attribute
filtering has been in the so called language we deployed to make it happen.
Since we have pseudo-formalized it in V3 [1] it at least becomes easier to
explain why it doesn't do what you expect. The parsing code is complex, but
robust (now); mind you the logic operations are "special cased" outliers
which actually makes it easier.

My concerns will come from the law of unintended consequences which when
dealing with attribute filtering is an all too common occurrence.  In this
case the question will come from what this degenerate case means when this
is running as a Matcher (when the operation runs over a set[2]), but after
some thought that the obvious behaviour (return the input for *BOTH* AND and
OR) is easily arguable to be correct and anyway we have somewhere to
document it [3,4].  It actually looks as though the code would "do the right
thing", but writing a hand full of tests won't hurt.

> . I definitely remember having a long conversation with *someone* about
what a 1-ary AND/OR (and 
> even a 0-ary AND/OR) meant at some point. 

Strange you should say that Ian, I have a memory of that too, I'm pretty
sure we ended up wondering whether de-Morganization worked.  But I don't
think it is in V3 - certainly not in attribute handling anyway.  I could
almost rationalize myself into believing that it was the discussion about
what logic over sets (or lists[2]) mean.  Or maybe it was that other
misguided attempt at "obvious" scripting that you and I worked on together
in our previous existences.  

I'll state now that I don NOT think that 0-ary AND/OR should be
considered...

To get back to the question OP's case.  It occurs to me that the need to
specify by a set of SPs is a common thing and it could well be that the it
is the same control that you might find on relying party configuration.  In
that case the PredicateRule might be a better plan - you end up only having
to maintain one list and you feed the same predicate into two places.

Indeed, for ease of configuration I would almost be inclined to prefer a
PredicateRule and an <bean parent="shibboleth.Conditions.RelyingPartyId" ...
/> over the current language.  The issue being that this requries two files
and needless separation.

/R

[1]
https://wiki.shibboleth.net/confluence/display/IDP30/AttributeFilterConfigur
ation#AttributeFilterConfiguration-Semantics
[2] Actually it's a list, but I really am not prepared to think about what
logical operations mean when applied to lists.
[3]
https://wiki.shibboleth.net/confluence/display/IDP30/BasicANDConfiguration
[4]
https://wiki.shibboleth.net/confluence/display/IDP30/BasicORConfiguration