Attribute release consent failing (sometimes)

Tom Zeller tzeller at
Wed Oct 11 09:27:04 EDT 2017

Hi Manuel,

> 4) We do not allow global consent or per-attribute consent.

If per-attribute consent is not allowed, perhaps the ExtractConsent
action could be modified to not store a "false" approval.

> 6) Not all failing attribute release consent attempts seem to raise a
> DEBUG message of net.shibboleth.idp.consent.flow.impl.ExtractConsent
> within the log files. There appear some new entries in the
> storagerecords table for context intercept/attribute-release with values
> containing "appr":false which I cannot find a corresponding DEBUG
> message for.

I find it curious that "false" approval is being stored without any logging.

> 7) For the failing attempts which were DEBUG-logged within the
> Shibboleth logs, I took a look at the User Agent in my loadbalancer's
> log. There I can see failing logins coming only from these specific
> browser versions (32 failures from 21-Sep-2017 thru 10-Oct-2017):
> Safari 10.0
> Safari 10.0.1
> Chrome 53.0.2785.143
> Chrome 54.0.2840.71
> Firefox 49.0

Given the diversity of browsers, I'm less inclined to blame them.

> Maybe I should just give up and disable the attribute release consent
> interceptor for this single service provider.

Before giving up, we could modify the ExtractConsent action to not
store a "false" approval if per-attribute consent is disabled. I think
that would workaround browser issues. I can work through that and
report back. If "false" approval is still being stored even after
modifying ExtractConsent, then it seems the bug is elsewhere.

I suggest you create an issue in JIRA.


More information about the users mailing list