Attribute consent display logic is still confusing

[Etienne Dysli-Metref]

On 26/11/15 15:26, Tom Zeller wrote:
> 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/.

Of course, but I'd rather give configuration advice to IdP deployers in
our federation than providing code they have to install.

On 26/11/15 15:33, Tom Zeller wrote:
> Oh, I am remembering emulating uApprove, I'd also need to review
> those docs and code, perhaps I confused myself in the process.

I had a quick look at uApprove's code. There is the method
resolveAttributes() in class ch.SWITCH.aai.uApprove.ar.SAMLHelper that
calls:

1. attributeProcessor.removeBlacklistedAttributes(attributes);
2. for each attribute:
   attributeProcessor.removeEmptyValues(attribute);
   attributeProcessor.removeDuplicateValues(attribute);
3. attributeProcessor.removeEmptyAttributes(attributes);
4. attributeProcessor.sortAttributes(attributes);

ch.SWITCH.aai.uApprove.ar.AttributeProcessor is the class implementing
these methods and receiving two lists of attributes in the configuration:

<bean class="ch.SWITCH.aai.uApprove.ar.AttributeProcessor"
      p:blacklist="${ar.attributes.blacklist}"
      p:order="${ar.attributes.order}"/>

So apparently, uApprove has no notion of a whitelist and always applies
the blacklist before sorting attributes.

HTH,
  Etienne

-------------- 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/20151127/7a686680/attachment-0001.sig>