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 63 Next »

Unknown macro: {div}

Browse a list of all current R&S SPs and IdPs

To have your IdP added to the list of IdPs that support R&S:

  1. read this wiki page completely
  2. configure your IdP for R&S (see below for [IdP deployment options])
  3. fill out a short form that declares your willingness and ability to support R&S

Once this is done, your IdP will be added to the list, normally within one business day.

For R&S SP Operators

To have an IdP added to the list of IdPs that support R&S, contact us at admin@incommon.org. We will reach out to the site admins for that IdP on your behalf.

IdP Deployment Requirements

An identity provider (IdP) supports the Research & Scholarship (R&S) Category 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. The following attributes constitute a minimal subset of the R&S attribute bundle:

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

For the purposes of access control, a non-reassigned persistent identifier is required. If your deployment of eduPersonPrincipalName is non-reassigned, it will suffice. Otherwise you MUST release eduPersonTargetedID (which is non-reassigned by definition) in addition to eduPersonPrincipalName. In any case, release of both identifiers is RECOMMENDED.

Testing IdP Support for R&S

Once you've configured your IdP (as discussed in the next section), you can test your configuration using this test page, a service provided by the GENI Experimenter Portal, an official R&S SP.

IdP 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 latest version of the Shibboleth IdP software supports all of these options out-of-the-box. (There are documented workarounds for earlier versions of the Shibboleth IdP.) No other IdP software is known to support entity attributes at this time.

Supporting R&S

Sites are strongly encouraged to configure their IdPs to support R&S, either by releasing the R&S Attribute Bundle directly to R&S SPs or by releasing the Essential Attribute Bundle to all SPs.

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 IdP 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? The answer is 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.

If you have further questions, please consult the R&S FAQ for IdPs.

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