Attribute consent display logic is still confusing

[Tom Zeller]

> On Nov 26, 2015, at 4:27 AM, Etienne Dysli-Metref <etienne.dysli-metref at switch.ch> wrote:
> 
> I find the logic that decides whether an attribute is displayed on the
> consent screen confusing. I mean the code of
> net.shibboleth.idp.consent.logic.impl.AttributePredicate [1], not the
> documentation in the wiki [2] (yet).
> 
> I want to have a whitelist of attributes to always show on the attribute
> consent screen with a specific order (from most personal to least). I
> also want to have a blacklist to hide cryptic identifiers. Finally, I
> want to have a catch-all safety regular expression so that any attribute
> I forget to put in the white or black lists is displayed.
> 
> To achieve this with the current code, I have to put the attributes I
> want to hide both in the blacklist AND in the whitelist (because
> attributes NOT in the whitelist are only checked against the match
> expression and my regex matches everything). That conflicts with my idea
> of a blacklist [3], weird.
> 
> Is there a way to configure attribute consent in order to achieve my
> goal above that doesn't induce cognitive dissonance? ;) Perhaps the
> relationship/priority between the blacklist and the match expression
> needs to be rethought...

I can respond more carefully with more time, but for now, you can always plug in your own predicate, with caveats about upgrading files in system/.

I'd have to look at the tests for that predicate, maybe I missed something.

> [1]
> http://svn.shibboleth.net/view/java-identity-provider/trunk/idp-consent-impl/src/main/java/net/shibboleth/idp/consent/logic/impl/AttributePredicate.java?view=markup
> [2]
> https://wiki.shibboleth.net/confluence/display/IDP30/ConsentConfiguration#ConsentConfiguration-AttributeDisplay
> [3] isDisplayed := (isInWhitelist OR matchesRegex) AND NOT isInBlacklist
>    In this case the regex is a "whitelist regex"