Attribute-based access control


The basis of federated access management is that the user, having been authenticated by their home organisation, which then releases attributes on their behalf, is authorised by an online resource provider to access their content.

Authentication is a statement made by an Identity Provider (IdP) that a particular user has demonstrated the use of valid local credentials.

Authorisation is a decision made by the Service Provider (SP), as to whether or not to grant the user access to the online resource the SP software protects.

This decision should be made not simply on the basis of a successful connection between the IdP and the SP (which only demonstrates that the two entities have access to each others' metadata), but on the basis of previously-agreed values of the attributes released by the IdP on behalf of the user. This allows the SP to be sure that not only is their resource being accessed by a member of an organisation entitled to access the content, but that the particular user is covered by the agreement.


In the majority of cases, the user's identity - who they are - is less important than what they are: student, member of staff, studying a particular subject, or working in a particular area. This information, and more, can be conveyed to the SP through the attributes their IdP releases.

From the IdP's point of view, if two sets of users can be distinguished in their organisation's LDAP or Active Directory, then different attribute values can be released on their behalf.

While SPs could all define their own attribute sets, it makes more sense for a federation to standardise on a particular set, so that all members of the federation can be sure that a particular attribute means the same thing to the IdP that releases it as it does to the SP that reads it.

The UK federation's standard attribute set, or core attributes, are derived from the 2003 and 2006 eduPerson Specifications (Development of eduPerson was originally created and supported with funding from Internet2, and was formally transitioned to REFEDS for management in October 2018).

Three attributes, given below in order of increasing specificity, relate to the user as an individual in a particular organisation:

  • eduPersonScopedAffiliation (ePSA). This attribute indicates the user’s position (staff, student, alumnus etc.) in their organisation. Many SPs find this sufficient information to decide whether or not to let the user access their resource. As hinted at above, this attribute has a restricted set of values, not all of which indicate that the user is covered by the license for a given resource. The organisation that a user belongs to is indicated by the security domain (or “scope”) applied to the affiliation, thus:
  • eduPersonTargetedID (ePTID). This attribute provides a unique, persistent, but pseudonymous, identifier that can provide for user registration, personalisation or the saving of results from one session to the next. It doesn't provide affiliation information, though, so this attribute tends to be used in conjunction with ePSA. There are two ways that the ePTID can be presented, an older and all-but-deprecated form presented as a scoped attribute containing a unique identifier and the IdP's security domain (only used in SAML1), and a newer version in the form of an ordered triple (containing the unique identifier and the entityIDs of the SP and the user's organisation's IdP ), which can be used in either SAML1 or SAML2.
  • eduPersonPrincipalName (ePPN). This attribute is a persistent, but non-anonymous (the value often corresponds to the user's login name) identifier, and should be considered as personal information. This is also presented as a scoped attribute.

In all three cases above, the SP is able to check whether a user comes from a particular organisation by checking the IdP's entityID (or scope in the case of the older version).

The final core attribute is used to indicate whether or not a user may access a particular resource or not:

  • eduPersonEntitlement (ePE). This attribute, whose value usually takes the form of an http- based URI (some older values are urn-based), indicates that a user satisfies the conditions that apply for access to a particular resource. Except in the case of an SP using an ePE value that corresponds to a specific license whose terms they are applying, SPs should create their own (when creating ePE values, http-based values are preferred, and it is useful if the value of the URL resolves to a document describing the value and purpose of the entitlement).

More detailed guidance on the use of the core attributes is provided in section seven of the federation's Technical Recommendations for Participants.

Data protection considerations

SP operators must comply with appropriate data protection and privacy legislation. Further, attributes may not be shared with other services or used for any purpose other than authorisation without either obtaining informed consent from each user, or by prior agreement with the organisation operating the IdP (which is then responsible for informing the users)

Nonetheless, where the potential benefits to the publisher outweigh the additional legal effort involved, some publishers may wish to obtain more personal information from users than allowed for by the core attributes:

  • If the accuracy of the information is essential (for example, it may be used to decide whether or not a user has access to confidential information), then this information may be obtained from the IdP in the form of "custom" attributes. However, this depends on the IdP both having the information needed, and being persuaded themselves that the information is sufficiently important to the SP that the benefits outweigh the risk.
  • If the accuracy of the information is important only to the user - information to personalise the site, for example - then the information can be given by the user directly through a webform, and the record indexed by their ePTID or ePPN as appropriate.

In either case, personal information remains personal information and can only be used in accordance with the law. For more details on the use of user data, please see section three of the federation's Recommendations for Use of Personal Data.

Use of attributes by SPs

In the vast majority of cases, one or more of the core attributes will suffice to allow a decision on authorisation. However, some SP operators may either require further information over and above that contained in the core attributes, or dispense with attributes entirely.

Additional attributes

There are two reasons SPs may ask for more than the standard core attributes. Either they want to collect more user information than is strictly necessary for authorisation, or they wish to exert a more finely-grained level of control over who can access which resources on their site.

These are both reasons why SPs may wish to use extra "custom" attributes. In these cases, they should consider using attribute definitions from existing schemata such as eduPerson, organizationalPerson, inetOrgPerson or SCHAC - also looked after by REFEDS, where the attributes have standard meanings, rather than varying the meaning and value of pre-existing attributes.

They should also consider that some IdPs will neither have, nor be willing to release, non-standard attributes (especially if privacy considerations apply), and that the added value given to the resource by the extra information should be definably "worth it" to the IdP and end users.

As an alternative to the collection of user information via attributes, the SP can simply ask users to fill in a registration form, where it is up to the user how much information they are prepared to share.

The alternative to the use of custom attributes for authorisation control is to provide the IdP operator with a suitable entitlement value which may only be released by users who fall into the correct category – this may or may not need additional information added to the organisation's AD/LDAP before the entitlement can be released.

Requesting Attributes

Until comparatively recently, resource publishers would need to ask IdP operators to release particular attributes to their SPs "out of band" - either by listing the attributes when the idP's owning institution signed up to access the resource, or by providing the information to the UK federation for publishing on our Attribute Usage web page and the associated links to individual service pages (which we are still happy to publish, by the way).

However, it is now possible for SPs to request that IdPs release particular attributes to them through the use of the RequestedAttribute stanza (NB: not all IdP software will read this information directly, but IdP operators can still pick it up and use it to configure their attribute-release policies manually).

Another way for the SP to indicate which attributes are required is through the use of the REFEDS Research and Scholarship entity category. SPs asserting membership of this category indicate that they require a specific minimal set of attributes. These attributes may be listed, as above, in RequestedAttribute elements in the SPs metadata, but it is not essential.

Authorisation without attributes

This is not recommended. An SP might authorise a user purely on the basis of their having connected via a particular IdP, but this should only be done when the SP operator is certain that the IdP only issues credentials to individuals who fulfil the SP's criteria for access.

Some SP operators take this a step further and assume that the presence of an IdP's metadata in the federation's metadata aggregate indicates that the IdP is automatically licensed to access their content. This is not, and never has been, the case. Further, as a result of interfederation through eduGAIN, the UK federation's metadata now contains a significant number of IdPs imported from overseas federations who may not have any contractual relationship with the SP.

As IdPs often provide credentials for users with an indirect association with the organisation, we recommend that SP operators only authorise users on the basis of attributes received. In particular, we would recommend that SPs keep up-to-date with their customers' metadata (NB some customers may have more than one IdP, or may change IdPs over time) and do not authorise access by IdPs they do not recognise.

Use of attributes for site customisation

As well as using attribute values to make authorisation decisions, SPs can use them to make decisions on what content to supply or to add appropriate branding to a page. This principle can be extended to allow the storage of search results, say, or registration information, for individual users.

Attribute release by IdPs

IdP operators in the UK federation are not obliged to release all four core attributes universally. However, they could release ePSA and ePTID, which are not personally identifiable information, to all SPs in the UK federation, while reserving release of ePPN (which is) and ePE only to those SPs that specifically require them.

Particular ePE values can be released for specific individuals, all authorised users, or any number of users in between as long as they can be distinguished in the organisation's directory.

However, IdPs that support the Research and Scholarship entity category (see above) agree to release the appropriate attribute bundle for a subset of its users to SPs that have the R&S entity category registered in metadata.

Other access considerations

Some publishers' license agreements indicate that their content may only be accessed within a particular geographical area. If a UK-based organisation has an overseas “out-station” that uses the same IdP as the home institution, then the available options include either having the overseas members release a different scope value or for the SP to require an appropriate entitlement value from the authorised users.

Another case that comes up from time to time is when an organisation has two disparate groups of users and a publisher has only licensed one of those groups to access particular content. The solution here should not be to change ePSA values for the unlicensed users, or even not to release ePSA for them, to that particular SP, but to add an eduPersonEntitlement value for the licensed group.