Consent needs to sort Attribute Values before hashing
Basics
Logistics
Basics
Logistics
Description
We have seen some inconsistencies in the order of multivalued attribtues between 3.4.7 and 4.0.1. This has caused the consent mechanism to state that the values have changed and re-prompts for consent in our environment.
Consider sorting sorting multivalued attributes before generating the consent hash.
This seems correct except that there was a duplication in how the hashing function was being configured and used, with an apparently unused slot on the flow descripror and a copy embedded inside the consent computing function. I changed the latter to use the former.
Scott Cantor January 14, 2021 at 10:34 PM
Edited
@Rod Widdowson While reviewing this, I noted the AttributeValuesHashFunction code is using cryptacular for the final hashing/base64 step. We probably want that using the java-support helpers for those to minimize the places we do that and limit the cryptacular touchpoints.
(ETA: I replaced them.)
Liam Hoekenga January 11, 2021 at 5:03 PM
Scott suggested that we use a scripted attribute to sort our "problem" attributes. We'll give that a try.
Rod Widdowson January 11, 2021 at 4:50 PM
Sadly, no - the change is not wide ranging but it affects some low level fundamental which means it is not a "just slide it in" fix.
Liam Hoekenga January 11, 2021 at 4:41 PM
A conversation with Scott made me release it may not be clear, we're using LDAP as the source of our attribute data.
We have seen some inconsistencies in the order of multivalued attribtues between 3.4.7 and 4.0.1. This has caused the consent mechanism to state that the values have changed and re-prompts for consent in our environment.
Consider sorting sorting multivalued attributes before generating the consent hash.