Attribute consent display logic is still confusing
Description
Environment
is related to
Activity
Tom Zeller December 19, 2015 at 6:59 AM
r8054
Applied fix to trunk.
Tom Zeller December 19, 2015 at 6:53 AM
r8053
Added new list to customize the attribute display order to 3.2 branch.
Tom Zeller December 1, 2015 at 9:48 PM
Reintroducing the order list is a minor version bump, I believe, because the configuration would not be identical. I guess we could provide a commented-out order list to stay within patch version compatibility if so desired.
Tom Zeller December 1, 2015 at 8:38 PM
Perhaps my mistake was conflating the whitelist and the order list. Reintroducing the order list may be the right thing.
Tom Zeller December 1, 2015 at 7:25 PM
Noting some history : the commit of the whitelist / blacklist / match expression was r6657
As noted on the users list referenced above, uApprove supplied two configuration knobs in uApprove.properties, ar.attributes.order and ar.attributes.blacklist :
#---------------------------------------------------------------------#
# Attribute Processing #
#---------------------------------------------------------------------#
# Defines the ordering of the attributes.
ar.attributes.order = uid \
surname \
givenName \
eduPersonPrincipalName \
eduPersonAffiliation \
eduPersonEntitlement
# Defines a list of blacklisted attributes.
ar.attributes.blacklist = transientId \
persistentId \
eduPersonTargetedIDWhile migrating, I thought that a whitelist was the natural counterpart to a blacklist, and together those would be general enough for user-space configuration. I assumed we had a whitelist / blacklist predicate somewhere, and we did. ValidateRemoteUser also came with a match expression. The whitelist / blacklist / match expression control the "consentable" attributes - the attributes which are displayed to the user for consent.
I also thought that the display of attributes to the user was at the presentation layer, and deployers would do whatever they want via Velocity templates, so attributes were originally displayed unordered (https://shibboleth.atlassian.net/browse/IDP-624#icft=IDP-624).
Re-using the v3 whitelist (the v2 "order" list) made sense to control the order in which attributes were displayed.
Attributes to be hidden must be defined in the blacklist AND whitelist.
"Attribute consent display logic is still confusing"
http://marc.info/?l=shibboleth-users&m=144853365432706&w=2