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:

• eduPersonScopedAffiliation
• eduPersonPrincipalName
• eduPersonUniqueId

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 duPersonPrincipalName 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 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

It is possible to register multiple Scopes in metadata, although it is usually not needed. A possible exception might be a single IdP servicing multiple security domains such as a university system with multiple campuses.  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. For example, the following use of scoped attributes is discouraged:

    user1@student.example.edu
    user2@faculty.example.edu

Instead use the eduPersonScopedAffiliation attribute (or the unscoped eduPersonAffiliation attribute) to disambiguate the eduPersonPrincipalName attribute, something like this:

     user1@example.edu
     student@example.edu

     user2@example.edu
     faculty@example.edu

A request to register multiple Scopes in the InComm metadata is not supported in Federation Manager and must be submitted separately via email to help@incommon.org.

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 if and only if the asserted scope matches a registered Scope value in metadata . 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

• SAML V2.0 Subject Identifier Attributes Profile Version 1.0: https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-subject-id-attr-v1.0-cs01.html
• SAML 2.0 Metadata Extension for Shibboleth: https://wiki.shibboleth.net/confluence/display/SC/ShibMetaExt+V1.0
• REFEDS eduPerson schema: https://refeds.org/eduperson