Attribute release consent failing (sometimes)

[Manuel Haim]

Hi,

it seems the n.s.i.consent.flow.impl.ExtractConsent=DEBUG setting just
gives me an entry within idp-process.log that is otherwise already
present in idp-consent-audit.log, e.g.:

20170907T113109Z|https://qis.uni-marburg.de/shibboleth|AttributeReleaseConsent|<principalname>|uid,eduPersonScopedAffiliation,eduPersonEntitlement,UniMrLinkToPeople|<hash>,<hash>,<hash>,<hash>|false,false,false,false

The same user managed, however, to reset his consent on the login screen
and finally give his consent successfully:

20170912T145555Z|https://qis.uni-marburg.de/shibboleth|AttributeReleaseConsent|<principalname>|uid,eduPersonScopedAffiliation,eduPersonEntitlement,UniMrLinkToPeople|<hash>,<hash>,<hash>,<hash>|true,true,true,true

I have to ask him if he used another webbrowser.

Meanwhile, I am pointing my loadbalancer only to one of my two IdP
nodes, looking if anything changes if no clustering is involved.

If nothing helps, I need to try idp.consent.compareValues=false

Kind regards,
Manuel


Am 13.09.2017 um 08:31 schrieb Manuel Haim:
> Thanks Tom,
> 
>> If you set the log level of
>> net.shibboleth.idp.consent.flow.impl.ExtractConsent to DEBUG, you
>> should see the attribute ids returned from the browser, as well as
>> whether isApproved is true or false. That should help determine if the
>> browser is the culprit (if you see isApproved=false instead of
>> isApproved=true).
> 
> I have added the following line to my idp.properties and will keep an
> eye on the logs:
> 
> net.shibboleth.idp.consent.flow.impl.ExtractConsent=DEBUG
> 
> By the way, removing the "checked" attribute from the hidden input
> within attribute-release.vm template didn't help yet.
> 
> 
>> Looks like idp.consent.compareValues is true (otherwise values are not
>> stored in consent storage records).
> 
> Yes, idp.consent.compareValues=true is also set, as users should be
> asked again for their consent on attribute changes.
> 
> Kind regards,
> Manuel
>