The Incommon Federation wiki has moved.

Please visit the new InCommon Federation Library wiki for updated content. Remember to update your bookmarks.

Click in the link above if you are not automatically redirected in 15 seconds.



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

Compare with Current View Page History

« Previous Version 23 Next »

Community Review in progress!

This document contains DRAFT material intended for discussion and comment by the InCommon participant community. Comments and questions should be sent to the InCommon participants mailing list (participants@incommon.org).

Default Attribute Release Policy

By definition, a default attribute release policy specifies a set of attributes to be released to any SP. To be clear, not all IdPs have such a policy. For example, most (if not all) of the IdPs in the Hide From Discovery Category do not have a default attribute release policy. On the other hand, a discoverable IdP necessarily has a default attribute release policy since it responds to all authentication requests by definition.

What is a discoverable IdP?

A discoverable IdP will be configured such that both of the following are true:

  1. The IdP consumes the metadata of all SPs

  2. The IdP responds to all authentication requests

An IdP that is unable (or unwilling) to do so is advised to self-assert membership in the Hide From Discovery Category.

Minimal Attribute Bundle

Like all IdPs, a discoverable IdP has an unspecified attribute release policy governed by local policy constraints. That said, an IdP easily satisfies the basic requirements of discoverability by releasing the following minimal attribute bundle to all SPs:

User identifier: SAML2 Transient NameID
User attribute: eduPersonScopedAffiliation

A policy based on the minimal attribute bundle is both easy to implement and privacy preserving. However, since the bundle lacks a persistent identifier, this approach lacks the basic interoperability characteristics sought by a typical federated SP.

 Policy Considerations

As shown in the previous section, it is easy to meet the basic requirements of discoverability—simply release no attributes by default! Your goal, however, should be true interoperability, which leads to an overall positive federated user experience. A reasonable default attribute release policy is the first step towards becoming truly interoperable.

But what is reasonable? Even though attribute release is a local policy decision, InCommon recommends the following minimal policy:

A reasonable attribute release policy for discoverable IdPs

An IdP with a reasonable default attribute release policy will, for some subset of the IdP's user population, release a persistent, non-reassigned identifier to all SPs (including global SPs) without administrative involvement, either automatically or subject to user consent.

Two aspects of the above definition deserve further discussion. First, the phrase “all SPs” refers to all SPs with metadata published in the InCommon metadata aggregate. That includes SPs registered by InCommon as well as SPs registered by other federations. That said, there will no doubt be exceptions to that general rule. For example, an IdP is certainly allowed to blacklist a “bad actor” SP at its discretion.

Second, the phrase “for some subset of the IdP's user population” gives the IdP some flexibility when implementing the policy. In other words, not all users need to have the same experience. For example, students need not be included in your initial focus group, which gives you time to think through the special case of students that fall under FERPA regulations. Such students might require an informed user consent flow to be implemented.

Crafting a Default Policy

Each of the following attribute bundles satisfies the above policy.

Attribute Bundle 1

The following bundle includes a persistent, non-reassigned identifier targeted at a specific SP:

User identifier: SAML2 Persistent NameID
User attribute: eduPersonScopedAffiliation

This bundle improves interoperability (compared to the minimal attribute bundle) while maintaining user privacy. However, a proper deployment of the SAML2 Persistent NameID (which is equivalent to eduPersonTargetedID) is a nontrivial endeavor and should not be taken lightly.

The following bundle represents a trade-off between privacy and deployability.

Attribute Bundle 2

The following bundle includes an easy-to-deploy persistent, non-reassigned identifier:

User identifier: SAML2 Transient NameID
User attribute #1: eduPersonUniqueId
User attribute #2: eduPersonScopedAffiliation

Since eduPersonUniqueId is not targeted (per SP), it lacks the privacy characteristics of the SAML2 Persistent NameID, but since every user has at most one eduPersonUniqueId, it is considerably easier to deploy. For an IdP that doesn’t already assert a persistent, non-reassigned identifier, this bundle is an attractive option.

The following bundle represents a further trade-off between privacy and deployability.

Attribute Bundle 3

For IdPs that already deploy eduPersonPrincipalName, the following attribute bundle may be simplest:

User identifier: SAML2 Transient NameID
User attribute #1: eduPersonPrincipalName (if non-reassigned)
User attribute #2: eduPersonScopedAffiliation

Since eduPersonPrincipalName is name-based (and therefore not opaque), it is the least private of all identifiers mentioned so far. However, eduPersonPrincipalName is widely deployed, so for many IdPs, this is the simplest option.

Note: If your deployment of eduPersonPrincipalName permits reassignment, please choose one of the other options shown above.

References

 

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels