Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Files: conf/idp.properties, conf/intercept/consent-intercept-config.xml, messages/message.properties, views/intercept/attribute-release.vm, views/intercept/terms-of-use.vm

...

Localtabgroup
tabStyleflat


Localtab
activetrue
titlePer-Attribute Consent

To allow users to select the attributes they wish to be released, provided the attributes are not being released via a back-channel exchange, you can set the idp.consent.allowPerAttribute property in conf/idp.properties.


Localtab
titleRejection

When a user rejects consent to attribute release, an AttributeReleaseRejected event will be signaled. The text presented to the user may be modified via standard ErrorHandlingConfiguration and via messages/messages.properties (see see the Messages tab below).


Localtab
titleAttribute Display

Localization

The names and values of attributes displayed during consent may be customized. By default, the locale-aware attribute display name and display value are displayed. Customizing the localization information is generally handled through the rules defined in the AttributeRegistryConfiguration.

Selective Display

By default, users are prompted to consent to release all attributes unless specifically suppressed on a per-attribute basis. Suppressed attributes are released to relying parties but are not displayed to users.  A prompted list, ignored list, and match expressions determine whether consent should be obtained for an attribute based on the attribute ID.

To prevent an attribute from being displayed, add the attribute ID to the ignored list or exclude it by a match expression. The ignored list and match expression override the prompted list.

TypeDescriptionBean name conf/intercept/consent-intercept-config.xml

Prompted

Attribute IDs for which users should be prompted to consent

shibboleth.consent.attribute-release.PromptedAttributeIDs 4.1

shibboleth.consent.attribute-release.WhitelistedAttributeIDs (DEPRECATED)

Ignored

Attribute IDs for which users should not be prompted to consent

shibboleth.consent.attribute-release.IgnoredAttributeIDs 4.1

shibboleth.consent.attribute-release.BlacklistedAttributeIDs (DEPRECATED)

Regex

Attribute IDs matching a regular expression that users should be prompted to consent

shibboleth.consent.attribute-release.MatchExpression
                                                                                                                 

Order

Attributes are, by default, displayed in the natural order of their IDs. Deployers may wish to customize the order in which attributes are displayed to users, in order to present the most relevant or personal attributes first.

The order in which attributes are displayed to users may be customized by providing a list of attribute IDs. Attributes not in the list will still be sorted in their natural order, but subsequent to attributes in the list. Define the bean named shibboleth.consent.attribute-release.AttributeDisplayOrder in conf/intercept/consent-intercept-config.xml representing the desired order. The values of the list are attribute IDs. 

The following example displays the mail attribute first and then all other attributes in alphabetic order by ID:

Code Block
languagexml
titleExample custom attribute display order in conf/intercept/consent-intercept-config.xml
collapsetrue
<util:list id="shibboleth.consent.attribute-release.AttributeDisplayOrder">
    <value>mail</value>
</util:list> 

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:

Code Block
languagexml
titleExample custom attribute display comparator in conf/intercept/consent-intercept-config.xml
collapsetrue
<bean id="shibboleth.consent.attribute-release.CustomAttributeIDComparator"
      class="org.example.CustomAttributeIDComparator" />



Localtab
titleConsent Duration

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.

Duration OptionDescription

"Ask me again at next login"

Users will be prompted to consent to attribute release at every log in. This is implemented by not storing consent.

"Ask me again if information to be provided to this service changes"

The default. Users will be prompted to consent to attribute release if attributes have changed since consent was previously given.

"Do not ask me again"

Optional. Users will not be prompted to consent to attribute release again. All attributes will be released to any service provider. The presence of this option is controlled by the idp.consent.allowGlobal property.



Localtab
titleValue Comparison

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.


...

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.

...