Deployment Considerations for the R&S Category

Service Providers

It is important that the deployment of all InCommon services facilitate initial on-boarding processes to avoid operational and technical impediments to adoption, as described in Recommended Practices for InCommon Participants.

More specifically, R&S services generally have a broad user community, often including people who do not have a close relationship with the Service Provider, or whose IdP operators do not have a close relationship with the Service Provider. For this reason, R&S Service Providers are encouraged to consider the following guidelines:

• The R&S category is most useful to those services that do not require out-of-band negotiation with IdPs.
• The service should request a subset of R&S Category Attributes, and furthermore, the service should request only those attributes it absolutely needs. (See the section on R&S Category Attributes for details.)
• The SP should fully support SAML V2.0 Web Browser SSO (see the SP Endpoints wiki page).
• The SP should provide a complete set of User Interface Elements in metadata. In particular, a Privacy Statement and a Logo are highly recommended.
• In addition to the technical and administrative Contacts in Metadata required of all SPs, a Security contact should also be provided (once that option becomes available).
• The SP should strive to provide a good, overall federated user experience. In particular, the SP should intelligently handle errors involving the release of attributes.

Identity Providers

IdP Support for R&S

An IdP supports R&S if, for some subset of the IdP's user population, the IdP releases a minimal subset of the R&S attribute bundle to R&S SPs without administrative involvement, either automatically or subject to user consent. A list of IdPs believed to support R&S is maintained elsewhere in this wiki.

The following attributes constitute a minimal subset of the R&S attribute bundle:

• eduPersonPrincipalName OR eduPersonTargetedID
• mail
• displayName OR (givenName AND sn)

To facilitate unambiguous access control, the persistent identifier (eduPersonPrincipalName OR eduPersonTargetedID) MUST be non-reassigned. Recall that eduPersonTargetedID is non-reassigned by definition.

Deployment Options

To support R&S, an IdP has at least three options (in increasing order of deployment difficulty):

1. Release a fixed subset of the R&S bundle (or the R&S bundle itself) to all SPs
2. Release a fixed subset of the R&S bundle (or the R&S bundle itself) to all R&S SPs (leveraging an entity attribute in SP metadata)
3. Release a varying subset of the R&S bundle to each R&S SP (depending on requested attributes in SP metadata)

The Shibboleth IdP software supports either of the first two options out-of-the-box. The latter option requires a special plugin at the Shibboleth IdP. No other IdP software is known to support entity attributes at this time.

The R&S category is the first of many such categories. Soon there will be multiple categories, for both SPs and IdPs, such that each category has its own entity attribute value. To support a given category, an additional software configuration similar to the R&S configuration is required.

The use of entity attributes (as opposed to entity IDs) has a significantly reduced administrative burden at the IdP. As the number of categories increases, however, the number of configurations increases as well. It is natural to ask if there is an even higher level of abstraction that further simplifies the administration of attributes? Yes, an IdP can release directory information to all SPs, not just R&S SPs. Such a configuration can simultaneously satisfy the attribute requirements of multiple categories.