IdP Consent: Different storage key bases for "Terms of Use" and "Attribute Release" consent flows

[Daniel Lutz]

For an upcoming feature of our centralized IdP we need to store "Terms of Use" consents
and "Attribute Release" consents with different base parts in the storage key. While "Terms of
Use" consents must be stored based on a unique identifier of the user, the "Attribute Release"
consents must be stored based on the user _and_ the issuer of the SAML assertion. Our IdP
will support SAML assertions issued by various issuers.

The current implementations of the "Terms of Use" and "Attribute Release" consent flows allow
the deployer to configure a function bean to look up the user-specific part of the key. This
can be done by setting the property "idp.consent.userStorageKey" to the appropriate bean
(defaults to "shibboleth.consent.PrincipalConsentStorageKey"). But both flows share
this single property (or default bean). This is not an option for us.

Instead, we would like to configure separate user storage key function beans
for the "Terms of Use" and the "Attribute Release" consent flows. A nice option
would be to have separate properties, e.g. "idp.consent.terms-of-use.userStorageKey"
and "idp.consent.attribute-release.userStorageKey", for configuring the function bean
the two flows should use.

Before filing an issue, I would like to ask for possible options we have.
I assume that a modification of the system flows "intercept/attribute-release"
and "intercept/terms-of-use" is required, but there may be other options.

The main problem is that the two flows "intercept/terms-of-use" and "intercept/attribute-release"
both define the bean "shibboleth.consent.UserStorageKey" by referring to the shared property
"idp.consent.userStorageKey" and the common default bean "shibboleth.consent.PrincipalConsentStorageKey".
Therefore, the deployer has no possibility to configure separate user storage keys.

Do you consider it as an option for a later release (e.g. 3.4) to support separate
user storage key functions for the two flows?

Or is there a simple way to configure an alternative bean "shibboleth.consent.UserStorageKey"
for the "intercept/attribute-release" flow without modifying the system configuration
(i.e. system/flows/intercept/attribute-resolver.xml), e.g. by defining an overriding
bean somewhere?

Or may we define our own flow, which uses "intercept/attribute-release" as parent and re-defines
the relevant bean? (I've tried this but haven't had success so far.)


Some further details of our setup:

Each user on this centralized IdP is identified by a unique identifier (a UUID) called
"swissEduID" (an example value is "0000a1a1-b2f8-42fa-852b-d768f8261e20"). This value is
well-suited as base for the key for storing "Terms of Use" consent, as it's independent
of the issuer of the assertion. Accepting the "Terms of Use" must be independent of the issuer.

On the other hand, the IdP supports multiple sets of attributes per issuer for each user.
(The goal of this is to consolidate multiple IdPs into a single one, therefore we have
multiple issuers and multiple sets of attributes). Among others, the attribute
"swissEduPersonUniqueID" has different values per issuer for the same user. Example values
are "12345 at uni-a.org" for issuer 1 and "9876 at uni-b.org" for issuer 2. This value is well-
suited as base for the key for storing "Attribute Release" consent, as it has some relation
to the issuer.

Our goal ist to use the value of "swissEduID" to store "Terms of Use" consents, and the
value of "swissEduPersonUniqueID" to store "Attribute Release" consents.


Thanks for considering this.


- Daniel