Standardized values for eduPersonEntitlement

Introduction

eduPersonEntitlement is a multiple valued attribute, each value a URI, representing a license, permission, right, etc. to access a resource or service in a particular fashion. Entitlements represent an assertion of authorization to something, precomputed and asserted by the identity provider. This attribute is typically used to assert privileges maintained centrally or remotely rather than within specific (local) application databases.
For more generic information see http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200806.html#eduPersonEntitlement.

Entitlements are always negotiated between SP and IdP.  Also, it makes little sense for a SP to request an entitlement if an IdP is not able or willing to provided such a value!

Using eduPersonEntitlement within SURFconext federation

Within SURFconext we want to standardise the way the values of this attribute are expressed, because:

• We want to scope the value of the attribute, so it is clear who is authoritative for its value(s) and prevent clashes between attribute values for different SPs (e.g. when two SPs both would need an 'admin' entitlement)
• We want to be able to filer this attribute in our ARPs (Attribute Release Policy) so specific value can be directed to specific SPs. As SURFconext currently (21-02-2014) does not support filtering on URL based attributes, it is recommended to only use URN based attribute values.
• As it has to be a URI, we want to attach a namespace that is compliant with namespace requirements for URNs. This will simplify national and international deployment of the attribute and its values.
• We do not want to create something new if in an international context a good alternative already exists.

Technically, eduPersonEntitlement MUST be a URI, either URN or URL. In case a URN is used, URN namespacing conventions MUST be applied. For more information on URN namespaces see http://en.wikipedia.org/wiki/Uniform_resource_name and the official RFC: https://tools.ietf.org/html/rfc3406. We note that in general using and registering formal namespaces is rather cumbersome. To circumvent the registration problem, while still remaining compliant with RFC3406 we allow x-surfnet to be used within SURFconext as an accepted custom namespace.

Specification

To meet the above requirements, values for eduPersonEntitlement for use within SURFconext MUST adopt the following formatting specification:

Generic Format

or

Whether or not to include an entitlementName as part of the value is up to the parties involved.

Identity Provider Specific Entitlements

In this case it is the IdP that defines the entitlement value. In general this is not very convenient, as this means the SP will need to interpret each entitlement value on a per IdP basis.

Note that the IDP namespace needs to be formally registered, or a prefix of x- needs to be used to signify a custom namespace.
e.g.:

• urn:mace:exampleIdP.org:demoservice:demo-admin
• urn:x-surfnet:surfnet.nl:sab:role:instellingscontactpersoon
  
  

Service Specific Entitlements

The common scenario when using eduPersonEntitlement is that an SP defines the attribute values it needs for its service. Please always check first if a generic attribute is not already available (e.g. eduPersonAffiliation, UID).
Note that even if the SP defines the attributes, the IdP is authoritative for the values being provided!

Note that the SP namespace needs to be formally registered, or a prefix of x- needs to be used to signify a custom namespace.

Examples:

• urn:mace:example.terena.org:tcs:personal-user
• urn:x-surfnet:surfdomeinen.nl:role:dnsadmin
• urn:x-surfnet:surf.nl:surfdrive:quota:100