Attribute consent display logic is still confusing

Etienne Dysli-Metref etienne.dysli-metref at switch.ch
Thu Nov 26 05:27:14 EST 2015


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...

  Etienne

[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".

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://shibboleth.net/pipermail/users/attachments/20151126/4993f014/attachment.sig>


More information about the users mailing list