Adding an attribute to a filtered

[phavekes]

This issue is imported from pivotal - Originaly created at Apr 25, 2019 by Bart Geesink

When the IdP sends the values of a multivalued attribute in a different order as before, consent is shown again.

Steps to reproduce:
Have EduPersonEntitlement enabled in the ARP
Log in using mujina, add two values for EduPersonEntitlement
Accept consent

Start another session
Log in using mujina, add two values for EduPersonEntitlement but now in opposite order
Consent is shown again

[phavekes]

need to discuss migration strategy (Thijs Kinkhorst - Sep 11, 2019)

[baszoetekouw]

Can still reproduce this.

The obvious solution would be to sort the attribute values before calculating the consent hash, but that would force all users who have previously given consent on non-alphabetically sorted attributes to give consent again. So as @thijskh remarked, we need a migration strategy to that.

So what we need to do (during a migration period of, say, 6 months) we can do the following:

• for each login, calculate two consent hashes: attributes in IdP-order and in sorted order
• check the sorted hash against the database; if this matches, everything is ok; continue the login
• if the sorted hash is not found, check the IdP-ordered hash
  • if it it found, don't show a consent screen, but do write the ordered hash to the database (so next time the ordered hash will match)
  • if it isn't found, show the consent screen as usual and (after consent) save the ordered hash.

After the migration period (doesn't have to be too long, because if a user logs into a service only once every 6 months, it's not really a big problem to show consent again), remove this logic and revert back tot the original logic (except using the ordered hash instead of the IdP-order).

[thijskh]

There is already a ticket for consent hash robustness and work in progress to make it.

However, I doubt it is a real world problem now.