Requested Attributes in SP metadata

RequestedAttribute elements allow an SP operator to signal to IdP operators the attributes that the SP can use.

For a typical e-journal use case, the eduPersonScopedAffiliation attribute is the only attribute that is required to allow access to protected content. However other SPs might include personalisations (saved searches, tailored content or display settings) which require a persistent and unique identifier for each user such as eduPersonTargetedID. And collaboration sites may request that the IdP releases email address for each user to allow notifications to be sent.

Requested Attributes are most useful for SPs that request attributes which are outside the UK federation's core attribute set. They are particularly useful for SPs that intend to interwork with IdPs outside of the UK federation, since there is no guarantee that other federations will define the same core attributes as the UK federation. Other uses cases are when the SP requires an email address or uid attribute (defined in RFC 4519).

The presence of an attribute in the RequestedAttribute element does not imply that the attributes are required, although that may be the case. It also does not imply that the IdP operator must release the attributes (or automatically does so). It is the IdP operator's responsibility to configure attribute release according to their organization's policy, and RequestedAttribute elements can inform that decision.

For further information on attributes and their usage see section 7 of the Technical Recommendations for Participants.

There is more information about Requested Attributes on the Shibboleth website.


As your SP is operating in a federated system, you should only request attributes which have been standardized, for example in the eduPerson specification or inetOrgPerson specification, and which have OIDs that are widely known.

Due to the extremely low numbers of SAML 1-only IdPs registered in the UK federation, and the simple syntax of the RequestedAttribute element, we recommend that only the OID-forms of attributes are listed in an SP registration, even if your SP supports SAML 1 (which typically would use urn:mace forms of attributes).

  • Ensure your SP is preferentially using SAML 2 over SAML 1. First, ensure that your SP is configured to prefer SAML 2 when in an SP-first flow (for example, from a login link on your SP). Secondly, check whether any accesses to your SP are from SAML 1 IdP-first login flows. Please contact the UK federation helpdesk for further advice and assistance in this area.
  • If your SP is SAML 1-only, you should upgrade it to SAML 2 operation before considering RequestedAttribute elements.

Procedure for adding RequestedAttribute elements

Let us know the SAML attributes your SP requires during registration. If the attributes are in the core set of UK federation attributes, you only need to include the name of the attribute, for example eduPersonScopedAffiliation & eduPersonTargetedID. If the attribute is outside the core set, please provide both the name and OID of the attribute to reduce ambiguity.

If your SP requires one or more attributes to make authorization decisions, please ask us to set the isRequired flag for those attributes. We have also heard that some other federations need the isRequired flag to automatically determine attribute release. Please contact the UK federation helpdesk for further advice and assistance in this area.

RequestedAttributes can also be added at any time after registration.

Example RequestedAttribute elements

This example is for an SP that can use all 4 UK federation core attributes, and which requests an email address.

        <AttributeConsumingService index="0">
            <ServiceName xml:lang="en">Your Service Name here</ServiceName>

            <!-- eduPersonScopedAffiliation -->
            <RequestedAttribute FriendlyName="eduPersonScopedAffiliation"

            <!-- eduPersonTargetedID -->
            <RequestedAttribute FriendlyName="eduPersonTargetedID"

            <!-- eduPersonPrincipalName -->
            <RequestedAttribute FriendlyName="eduPersonPrincipalName"

            <!-- eduPersonEntitlement -->
            <RequestedAttribute FriendlyName="eduPersonEntitlement"

            <!-- inetOrgPerson: mail -->
            <RequestedAttribute FriendlyName="mail"


Last updated 2017-01-25: Recommendations updated to include only SAML2 / OID forms of attributes