...
- 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 requested attributes. InCommon now operates a centralized Error Handling Service that SPs can use to report errors to users.
Identity Providers
Release of R&S Attributes
An IdP supports R&S if the IdP releases some subset of the R&S attribute bundle to R&S SPs without administrative involvement, either automatically or subject to user consent. To support R&S, an IdP has at least two options:
...
Sites are strongly encouraged to configure their IdPs to support R&S.
It is expected that sites will readily release attributes for faculty, researchers, and staff since these people already routinely share this information with their collaborators. If a site decides 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 rule to enforce this decision. IdP addons that provide end-user control over attribute release (such as uApprove) may also be used.
Release of Directory Information
The R&S Category is the first of many such categories. Soon there will be multiple categories, for both SPs and IdPs, with each category having its own entity attribute value. Entities will of course choose which of these categories to support. Each supported category requires a software configuration similar to the R&S configuration.
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. Is there an even higher level of abstraction that further simplifies the administration of attributes? Yes there is.
- Release a fixed subset of the R&S attribute bundle (or the R&S bundle itself) to all SPs, not just R&S SPs
Many campuses expose so-called directory information via their public web site. Although the policy associated with this directory information varies from campus to campus, it’s not unreasonable to expect that some campuses will choose to expose this very same directory information via a SAML interface. There should be little discussion or controversy over releasing directory information for faculty, researchers, and staff since directory information is already public information.
It is highly likely that directory information will include some subset of the R&S attributes. We can leverage this fact by configuring an attribute release policy that releases directory information to any SP, including R&S SPs. Such a configuration can simultaneously satisfy the attribute requirements of multiple categories.
| Attachments |
|---|