Page tree
Skip to end of metadata
Go to start of metadata

Jump to: 

A Scope is an element defined in the SAML V2.0 Subject Identifier Attributes Profile Version 1.0 (see section 3.5.2, Scope Filtering). An identity provider (IdP) operator registers Scope(s) with the Federation Operator (InCommon) when registering its IdP. The Federation Operator validates that the domain name in the Scope belongs to the IdP organization. A service provider in turn uses the IdP's registered Scope to validate the scoped value the IdP sends in its SAML assertions.

A Scope takes the form of a domain name. A registered Scope must be of a domain belong to the registering organization.

Scope helps a Service Provider verify these scoped attributes defined in the REFEDS eduPerson schema and the SAML v2.0 Subject Identifier Profile:

  • eduPersonScopedAffiliation
  • eduPersonPrincipalName
  • eduPersonUniqueId
  • SAML2 General Purpose Subject Identifier
  • SAML2 Pairwise Subject Identifier

Each of these attributes express values in a string-valued attribute of the form:

     value@scope

For example, the value of eduPersonPrincipalName for Internet2 staff is:

     username@internet2.edu

A Service Provider (SP) compares the scoped values sent by the IdP in a SAML assertion with the IdP's registered Scope(s) in metadata to make sure that the values are valid (for example, that the IdP did not try to assert an eduPersonPrincipalName that belongs to another institution).

Scope in metadata

The permissible scopes are expressed in the  IdP metadata:

<md:Extensions xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
  <shibmd:Scope regexp="false"
      xmlns:shibmd="urn:mace:shibboleth:metadata:1.0">internet2.edu</shibmd:Scope>
</md:Extensions>

The Federation Operator is the  authoritative registrar for the <shibmd:Scope> element in metadata. When an IdP metadata is submitted, the InCommon Federation Operator ensures that the submitted scope is the primary domain of the organization that owns the metadata. Any exceptions requires separate petition and is vetted by the Federation Operator on a case by case basis.

Since scoped attributes may be used for access control, they often end up on access control lists at the SP. Therefore scope values, once published in metadata, should not be changed. If your primary domain changes (which happens occasionally), it might be better to actually publish two scope values in metadata for a time, which gives the IdP operator more flexibility to develop an effective migration strategy.

Multiple Scopes in metadata

IMPORTANT: To request the registration of multiple Scope for your entity, please contact the InCommon Registration Authority at help@incommon.org. Federation Manager does not allow a Site Administrator to register multiple Scopes within an entity.

Although rarely needed, it is possible to register multiple Scopes in an InCommon-published metadata. For example, a single IdP servicing multiple security domains such as a university system with multiple campuses might need to register multiple scopes. Even in that case, the organization may wish to register multiple IdP entity descriptors—each with its own scope—for branding and other UI display reasons.

Multiple scopes should not be used to distinguish multiple subgroups of users within a single security domain. Instead, use the eduPersonScopedAffiliation attribute (or other attributes intended to convey group membership) to express a person's relationship or unit within an organization. For example:

DO NOT USE: 

  • eduPersonPrincipleName = user1@student.example.edu
  • eduPersonPrincipleName = user1@dept1.example.edu (when there is only one IdP representing the entire example.edu organization)

DO USE: 

  • eduPersonPrincipleName = user1@example.edu, combined with eduPersonScopedAffiliation = student@example.edu
  • eduPersonPrincipleName = user1@example.edu, combined with isMemberOf = dept1@example.edu

Evaluating scoped attributes

Upon receiving a scoped attribute from the IdP, SP software supporting the Scope syntax can be configured to compare the asserted scope to the scope value(s) in metadata.  The scoped attribute is accepted by the SP only if the asserted scope matches a registered Scope value in metadata. We strongly recommend this practice. It ensures that the IdP is sending only user data values for which it control.

The Shibboleth SP software is configured this way by default. Other SP software may require explicit configuration. 

Not all attribute values with a "@" are scoped

It's worth noting that not every attribute whose value contains an '@' character is "scoped" in this context. For example, an email address has an '@' and always contain a domain qualifier. However, it is not typically processed by scope-aware SAML software for the purpose of assertion validation. 

Another example, eduCourseMember, has values that consist of a role and a course, separated by an '@' delimiter. However the course identifier is an URI, not a domain, and is not a "Scope" as discussed in this article.

References