Along with cross-domain SSO, attribute sharing is a primary benefit of federated access to resources. To facilitate the sharing of attributes, Federation participants conform to the MACE-Dir SAML Attribute Profiles, which specify the syntax of SAML attributes "on the wire." The scoped attributes
eduPersonScopedAffiliationeduPersonPrincipalNameeduPersonUniqueId
have a special syntax. Each is a string-valued attribute of the form
value@scope
For example, the value of eduPersonPrincipalName for Internet2 users is:
username@internet2.edu
As illustrated in the previous example, a scope is typically a DNS domain. In the case of eduPersonUniqueId, the scope actually is a DNS domain.
Note that not every attribute whose value contains an '@' character is actually "scoped" in this sense. For example, email addresses are similar in form, and always contain a domain qualifier, but are not typically processed by SAML software as discrete "value" and "domain" components.
Another example, eduCourseMember, has values that consist of a role and a course, separated by an '@' delimiter. But the course identifier is an URI, not a domain, and is not a "scope" for the purposes of the policy concepts discussed below.
Acceptance of Scoped Attributes
After receiving a scoped attribute from the IdP, some SP software 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 scope value in metadata. The Shibboleth SP software is configured this way by default. Other SP software may require explicit configuration or in some cases may not support the <shibmd:Scope> element at all.
Scopes in Metadata
To prevent an IdP from asserting arbitrary scoped attributes, the permissible scopes are called out in 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 in effect authoritative for the <shibmd:Scope> element in metadata. When IdP metadata is submitted, the RA ensures that the submitted scope is the primary domain of the organization that owns the metadata. Otherwise a manual vetting process is triggered.
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.