idp.consent.userStorageKeyAttribute attribute not available when consent flow runs

[Tom Zeller]

On Tue, Jul 7, 2015 at 10:34 AM, Etienne Dysli-Metref
<etienne.dysli-metref at switch.ch> wrote:
> Hello,
>
> I'm seeing the line below in the logs when a consent flow runs (either
> terms of use or attribute release):
>
> DEBUG [net.shibboleth.idp.consent.logic.AttributeValueLookupFunction:93]
> - Attribute 'swissEduPersonUniqueID.withoutAttributeEncoder' does not
> exist or has no values
>
> even though that attribute produced one value when resolved. Then the
> generated key contains only the SP's entityID and this causes consent
> decisions to ignore the user being authenticated (e.g. the first user to
> ever log in on the IdP gets the ToU prompt then nobody else gets it, for
> a given SP).

Sounds like a bug.

> The attribute configured here
> "swissEduPersonUniqueID.withoutAttributeEncoder" is an encoder-less
> version of the swissEduPersonUniqueID so it won't be released. Now the
> questions: must the attribute used by consent flow storage
> (idp.consent.userStorageKeyAttribute property) be 1) encoded 2) released
> by filtering? or is it subject to other prerequisites in order to be
> available in consent flows?

I believe the attribute must be released. The fix is for the
AttributeValueLookupFunction to retrieve that attribute from the set
of unfiltered attributes, see IDP-729.