Page Comparison

...

1. on initial access to service provider resources
2. on release of an attribute to which consent has not been previously given
3. when an attribute previously consented to is no longer released
4. (optionally) when the value of an attribute previously consented to changes, see Attribute Release Value Comparison 2691694624.

Attribute release consent is enabled for profiles that do user authentication via the postAuthenticationFlows property in conf/relying-party.xml.

...

<bean id="shibboleth.consent.attribute-release.

CustomAttributeIDComparator" class="org.example.CustomAttributeIDComparator" />

For advanced customization of the attribute display order, a custom Comparator may be provided. Define a bean named shibboleth.consent.attribute-release.AttributeIDComparator in conf/intercept/consent-intercept-config.xml which implements Comparator<String>. For example:

<bean

id="shibboleth.consent.attribute-release.CustomAttributeIDComparator"

 class="org.example.CustomAttributeIDComparator"

/>

Users may choose from three options when deciding the duration of their consent to attribute release. The duration options and descriptive text may be customized via messages/messages.properties.

By default, users are prompted to consent to attribute release if a "new" attribute is released or if an "old" attribute is no longer released. "New" and "old" in this context indicate whether consent has already been given to an attribute ID regardless of the attribute's values. In other words, by default, users are not prompted to consent to attribute release if an attribute's values change.

To prompt users to consent to attribute release if the values of an attribute have changed, set idp.consent.compareValues to true in conf/idp.properties

Prompting users to consent to attribute release if an attribute's value changes requires additional storage capability, because the hash of an attribute's values must be stored for comparison. If client-side storage without use of HTML Local Storage is used to store consent, comparing attribute values may reduce the number of records that may be stored. Since a consent record is stored for every Service Provider, this may increase how often users are prompted to consent to attribute release

Terms Of Use Consent

Consent to terms of use is not enabled by default. To enable it, you will need to :

...

The "terms" are managed as Spring messages via the messages/messages.properties file (or localized versions of it) (see Messages2691694624).

The title and message of the terms of use page displayed to users is derived using the bean named shibboleth.consent.terms-of-use.Key, which defaults to the relying party ID. For example:

...

When a user rejects consent to terms of use, a TermsRejected event will be signaled. The text presented to the user may be modified via standard ErrorHandlingConfiguration and via messages/messages.properties (see Messages2691694624).

User Interface

The user interface for the attribute release and terms of use consent flows are implemented as Velocity templates, views/intercept/attribute-release.vm and views/intercept/terms-of-use.vm respectively.

...

While the default client-side storage solution is HTML Local Storage, it is possible to use cookies. Because cookies provide limited storage capability, the number of stored consent records is also very limited. By default, for client-side storage via cookies, the maximum number of stored consent records is 10. Depending on the number of attributes released and whether released attribute values are compared, the default limit of 10 may be increased. It is not clear what a reasonable default value should be, but it may be significantly higher. We were conservative with the default.

If server-side storage is used, the number of stored consent records should probably be unlimited, represented by a limit of -1 or 0.

The maximum number of stored consent records is configured via the idp.consent.maxStoredRecords property in conf/idp.properties

A map is supported to store numbers which refer to attribute IDs in order to reduce the size of consent storage records if desired. The default mapping of attribute IDs to numbers is defined by the shibboleth.consent.DefaultAttributeSymbolics bean, internally to the system.

Additional mappings may be added to the shibboleth.consent.AttributeSymbolics bean in conf/intercept/consent-intercept-config.xml

The default lifetime for consent storage records is 1 year, and may be configured via idp.consent.storageRecordLifetime in conf/idp.properties. When consent storage records expire, they will no longer by visible via the storage service. Actual timing of deletion is specific to the storage implementation.

{  
   "jdoe:https://sp1.example.org":{  
      "v":"[{\"id\":307},{\"id\":\"mail\"},{\"id\":\"uid\"}]",
      "x":1479847202110
   },
   "jdoe:https://sp2.example.org":{  
      "v":"[{\"id\":307},{\"id\":\"mail\"},{\"id\":\"uid\"}]",
      "x":1479847206825
   },
   "jdoe:https://sp3.example.org":{  
      "v":"[{\"id\":307},{\"id\":\"mail\"},{\"id\":\"uid\",\"appr\":false}]",
      "x":1479847566214
   },
   "jdoe:_key_idx":{  
      "v":"[\"jdoe:https://sp1.example.org\",\"jdoe:https://sp2.example.org\",\"jdoe:https://sp3.example.org\"]"
   }
}

...

Because the attribute release flow has an internal condition attached already, customizing the condition for it requires combining the default activation condition with the custom activation condition. By default, the attribute release flow is not activated if both (1) attributes are not pushed and (2) per attribute consent is enabled.

The terms of use flow does not have a default activation condition.

...