Uploaded image for project: 'Identity Provider'
  1. Identity Provider
  2. IDP-1228

Attribute release consent fails (sometimes)

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 3.3.1
    • Fix Version/s: None
    • Component/s: Attribute Consent
    • Labels:
      None
    • Environment:

      Debian GNU/Linux 9

    • Operating System:
      Linux
    • Java Version:
      Other OpenJDK 8
    • Servlet Container:
      Apache Tomcat 8

      Description

      When accepting the information release page (with idp.consent.allowPerAttribute=false), some of our users report that no attributes are passed on to the service provider.

      This happens (up to now) only for one of our service providers, and only for users coming from the following browsers (looked up by request header "User-Agent"):

      Chrome 53.0.2785.143 (released 31-Aug-2016)
      Chrome 54.0.2840.71 (released 12-Oct-2016)
      Safari 10.0 (released 20-Sep-2016)
      Safari 10.0.1 (released 24-Oct-2016)
      Firefox 49.0 (released 20-Sep-2016)

      Older or newer versions of these browsers seem not affected. (The above versions were released at about the same time, maybe they share the same bugs?!)

      For the failing attempts, with DEBUG logging for net.shibboleth.idp.consent.flow.impl.ExtractConsent enabled, we see either messages like this (in most cases):

      2017-10-11 09:38:36,117 - DEBUG [net.shibboleth.idp.consent.flow.impl.ExtractConsent:93] - Profile Action ExtractConsent: Consent context 'ConsentContext{previousConsents={}, chosenConsents={uid=Consent{id=uid, value=<SomeHash>, isApproved=false}, eduPersonScopedAffiliation=Consent{id=eduPersonScopedAffiliation, value=<SomeHash>, isApproved=false}, eduPersonEntitlement=Consent{id=eduPersonEntitlement, value=<SomeHash>, isApproved=false}, <SomeCustomAttribute>=Consent{id=<SomeCustomAttribute>, value=<SomeHash>, isApproved=false}}}'

      Or messages like this (in only few cases):

      2017-10-11 09:48:12,797 - DEBUG [net.shibboleth.idp.consent.flow.impl.ExtractConsent:75] - Profile Action ExtractConsent: No consent choices available from user input

      So it seems the browser doesn't POST the required data from the <input type="hidden"> fields.

      As Tom Zeller suggested, an easy fix would be to modify the ExtractConsent action to not store a "false" approval if idp.consent.allowPerAttribute=false is set.

      We have the following values set in idp.properties (with default values commented out):

      idp.consent.storageService = shibboleth.JPAStorageService
      idp.consent.userStorageKey = shibboleth.consent.AttributeConsentStorageKey
      idp.consent.userStorageKeyAttribute = uid
      # idp.consent.allowDoNotRemember = true
      idp.consent.allowGlobal = false
      # idp.consent.allowPerAttribute = false
      idp.consent.compareValues = true

        Attachments

        1. marvin.uni-marburg.de.xml
          7 kB
          haimm@idp.protectnetwork.org
        2. qis.uni-marburg.de.xml
          9 kB
          haimm@idp.protectnetwork.org

          Issue Links

            Activity

              People

              • Assignee:
                tzeller@shibboleth.net Tom Zeller
                Reporter:
                haimm@idp.protectnetwork.org haimm@idp.protectnetwork.org
              • Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: