The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

UserConsent

Owned by Former user (Deleted)
Last updated: Sept 22, 2008Version comment
3 min read

Scalable Attribute Release w/ User Consent

In all Shibboleth releases up through the current one (2.1), attribute release is solely managed by a site administrator who maintains the Attribute Filtering Policies (AFPs). These policies are generally written so that they apply to a given SP or group of SPs. There are some problems with this approach:

  • SPs cannot always be grouped in order to simplify AFP rule management; however, writing a unique policy for each SP is not administratively scalable
  • Administrators must be aware of new SPs that come online and make sure that existing policies release only the appropriate data.
  • User's are not involved in the process that releases their information. They cannot opt-out of this release.

The proposed solution is:

  1. Use the SWITCH ArpViewer to allows users to participate in the release process. This extension to Shibboleth 1.3 and 2.0 has several functions, and can be configured to operate in several different modes. In its most basic mode, however, the first time a user visits a new SP the IdP will present the user with a web form listing the attributes that are being released and asking the user to "approve" the release. If the user clicks YES, the ArpViewer remembers the choice and redirects the user to the SP. If the user clicks NO, the process stops. Note that the user cannot individually control attributes and values for release; they can only approve or reject the entire transaction.
  2. Create a new AFP policy rule, described below, that uses a service provider's metadata to influence what is released.

We think this will make use of the SWITCH ArpViewer highly scalable. A site will decide which of the attributes listed in an SPs metadata can be released without further rules. The ArpViewer can then be used to gain user consent for this release. Note that this approach requires a change in how Federations maintain their metadata -- they would have to populate the  AttributeConsumingService element of the SPs in their metadata.

New AFP Rule

For the sake of this discussion we will call this new function AttributeInMetadata. When this function is specified on a PermitValueRule element, it would check to see if the enclosing attribute was listed in the requesting SP's AttributeConsumingService metadata element. If there is a match, then the Rule returns TRUE. This type of match function could also have options specifying whether to release optional attributes and whether to filter on values too (since this is allowed in the metadata, but would be expensive to implement).

Given the proposed matching function a site would do the following to use it.

  1. Ensure that Service Providers list, in their metadata, those attributes that are required and optional for proper operation.
  2. Create an AFP covering those attributes. Each attribute would list a single PermitValueRule of type AttributeInMetadata. Note, this does not affect how the PolicyRequirementRule is specified so this rule could be applied to a requester using the same logic as any other policy. So the rule could be applied to all SPs, only those in a certain group, specific SPs, etc.
  3. Install and configure the SWITCH ArpViewer. Strictly speaking, this is not required. However, taking the above steps without using the ArpViewer creates a situation that is extremely dangerous to the effective management of personal privacy.

Here is an example configuration snippet that release ePPA to any SP in InCommon that lists that as a required attribute:

<AttributeFilterPolicy id="releaseRequiredToInCommon">
    <PolicyRequirementRule xsi:type="saml:AttributeRequesterInEntityGroup" groupID="urn:mace:incommon" />
    <AttributeRule attributeID="eduPersonPrimaryAffiliation">
        <PermitValueRule xsi:type="saml:AttributeInMetadata" />
    </AttributeRule>
</AttributeFilterPolicy>