Page History

...

Deployment Considerations for the R&S Category

...

...

It is important that the implementation and 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 IdPs 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 technical and Administrative administrative Contacts in Metadata required of all SPs, a Security security contact should also be provided (once that option becomes available).
• The SP should strive to provide a good, overall Federation User Experience federated user experience. In particular, the SP should should intelligently handle errors involving the release of requested attributes. InCommon now operates a centralized Error Handling Service that SPs can use to report errors to users.

Identity Providers

Supporting Problem Resolution

To reduce user confusion and frustration, R&S SPs will try to display a  page providing the user with specific instructions in the event the user is returned to the SP without sufficient attributes. The IdP can help this process by including an errorURL in metadata (the linked page provides suggestions for the content of the error page). When an error occurs, the SP would display a page containing this link; the user could return to the IDP and see a description of how to proceed to get the problem resolved. This gives the IdP the ability to own this problem by documenting (on the error page) and supporting whatever error handling process it desires.

Configuring an IdP to Release Attributes to an R&S SP

Information is provided describing how to Configure a Shibboleth IdP to Release Attributes to an R and S SP.

No other IdP implementation is known to support entity attributes in SP metadata.

Further Policy Controls

If a campus determines that it wants to block release of attributes for certain community members (e.g., students who have opted out under FERPA), IdP operators could create an additional attribute release policy to enforce this decision. An example is available on the Shibboleth wiki. IdP plugins, such as uApprove, that provide end-user control over attribute release may also be useful to satisfy additional controls.

Metadata Support for the R&S Category

Upon approval, the following R&S entity attribute is inserted into SP metadata:

<mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
  <saml:Attribute
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
      Name="http://id.incommon.org/attribute/entity/category">
    <saml:AttributeValue>http://id.incommon.org/category/research-and-scholarship</saml:AttributeValue>
  </saml:Attribute>
</mdattr:EntityAttributes>

Assuming other SP categories are added in the future, an SP belonging to multiple categories would have a single entity <saml:Attribute> with multiple <saml:AttributeValue>'s.

...