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.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

In all Shibboleth releases up through the current one (2.1), attribute release is managed by a site administrator maintaining Attribute Release Policies (ARPs). ARPs are associated with SPs (or groups of SPs). There are some problems with this approach:

  • This clearly isn't scaleable to a large number of SPs. 
  • There is no user involvement. There is a growing amount of interest in giving the user direct control over the release of attribute information that describes them.

These changes, taken together, are an attempt to address these issues. The proposed solution includes:

  1. The SWITCH ArpViewer. 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. The proposed new AFP matching function. We think this will make use of the SWITCH ArpViewer highly scaleable. A site will identify in its filter rules which attributes require user approval before release. Accessing a site requesting one of those attributes will trigger presentation of the ArpViewer.

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.

 Here is some additional detail describing how this would work:

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 SPs 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 all the required, and optionally optional, attributes needed in order to access and use their service.
2. On the desired attributes, configure the new matching rule as a PermitValueRule for each attribute you wanted to treat like this.  You could, through the policy's PolicyRequirementRule have this policy take effect for particular SPs, SPs that aren't particular SPs, SPs in groups or not in groups, etc. All current policy rules still work.

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 config that release ePPA to any SP in InCommon that lists that as a required attribute

<AttributeFilterPolicy id="releaseRequiredToInCommon">
    <PolicyRequirementRule xsi:type="saml:ttributeRequesterInEntityGroup"
                                           groupID="urn:mace:incommon" />

     <AttributeRule attributeID="eduPersonPrimaryAffiliation">
          <PermitValueRule xsi:type="AttributeInMetadata" />
     </AttributeRule>
</AttributeFilterPolicy>

  • No labels