Consent to release attributes in a Shibboleth v3 IdP

Version 3 of the Shibboleth IdP includes functionality that asks account holders to consent to the IdP sending attributes about them to an SP. This functionality was not in the Shibboleth v2 IdP, and is not enabled by default if you use the v2 to v3 upgrade script.

After authentication has taken place, the IdP will resolve attributes about the subject and determine which of those should be released to the SP. The IdP then intercepts the flow with a web page asking the account holder if they consent to the release of these attributes. This is what is displayed if you attempt to access the UK federation Test SP and then authenticate as the persona "Beth" at the UK federation Test IdP:

Consent page from IdP, asking for consent to release attributes

The user is presented with a list of attributes and their values, and is asked to reject or accept sending these attributes to the SP. The actual attributes and their values are specific for each user/SP combination.

In this example eduPersonAffiliation, eduPersonEntitlement and eduPersonScopedAffiliation do not contain personal information. The remainder of the attributes may include personal information and the user may not wish to release those attributes to the specific SP. The IdP also releases some targetedIDs, but these are pseudonymous so we've configured the IdP not to ask for consent for that. There is a flexible mechanism, configured in %{idp.home}/config/intercept/consent-intercept-config.xml, which allows you to choose which attributes to ask for consent for, and the order in which they're displayed.

Reference documentation for the consent configuration is at https://wiki.shibboleth.net/confluence/display/IDP30/ConsentConfiguration. It also includes:

  • Details about the main configuration options in %{idp.home}/conf/idp.properties
  • Enabling per-attribute consent
  • Displaying a Terms of Use page
  • Showing the consent page depending on particular activation conditions

Example configuration

We following example configuration could be used, this ensures users only see the consent notification where personal information is being released, but for identifiers and affiliations they do see the notification.

Within in %{idp.home}/config/intercept/consent-intercept-config.xml, add <value> statements for eduPersonTargetedID.old eduPersonScopedAffiliation eduPersonAffiliation and eduPersonEntitlement, within the shibboleth.consent.attribute-release.BlacklistedAttributeID list. The section of configuration should now look like this; 

    <util:list id="shibboleth.consent.attribute-release.BlacklistedAttributeIDs">
        <value>transientId</value>
        <value>persistentId</value>
        <value>eduPersonTargetedID</value>
        <value>eduPersonTargetedID.old</value>
        <value>eduPersonScopedAffiliation</value>
        <value>eduPersonAffiliation</value>
        <value>eduPersonEntitlement</value>
    </util:list>

Frequently asked question

The UK federation support team are frequently asked if these consent pages can be removed. There are a couple of options about how you could progress technically, and you should consider your College's Data Protection policy when deciding which one to follow. We also provide Recommendations for the use of personal data that may inform your decision.

You can find the configuration changes in the reference documentation, which is linked to above.

1) Disable attribute release consent for all users, so that you as the IdP operator determine which attributes are released. This requires a simple change on two lines of %{idp.home}/conf/relying-party.xml. See "Disabling Attribute Release Consent" in the reference documentation.

2) Customize the page so that attributes without personal information are sent without consent, and ask for consent for the personalised information. This is controlled by the whitelist and blacklist util:list elements in %{idp.home}/conf/intercept/consent-intercept-config.xml. If you wish to change these from the default values, you will need to edit the lists. See "Attribute Display" in the reference documentation.

3) Display the pages only when certain activation conditions are met, for example only display pages for user accounts which have a staff affiliation. This is a flexible mechanism built into the IdP, although you will need to write some code. See "Activation Conditions" in the reference documentation.