Granular authorisation

As well as the ability for organisational units to have different scopes, a surprising amount of granularity of access is possible via the attributes passed from an IdP to an SP.

A common example would be a University or College using the role attribute to identify which users were students, and which were staff or perhaps alumni. This would allow the SP to show content appropriate to those types of user. A user may present multiple values for the role attribute so an 'is allowed if role is X' approach is usually more appropriate than an 'is not allowed if role is Y' one.

You can go further though. Let us suppose that a University library cannot afford to purchase access to a set of Physics journals based on all 80,000 members of the library. Rather than lose a sale an SP might choose to sell them a licence for only the 1000 strong Physics department so long as the IdP could pass them an attribute that identified if the users were physicists. This would typically be handled by a standard attribute (entitlement - urn:oid:1.3.6.1.4.1.5923.1.1.1.7) and the SP would simply ask the subscriber to pass the an agreed entitlement value of, say, 'physics' for just those relevant users. The SP would look for this attribute and value and only show the physics content to users that had it.

This kind of granularity has always been possible for IdPs in the OpenAthens federation.

Can IdPs send SPs anything else?

In addition to the standard attributes, there are some extended attributes that, whilst not suitable for authorisation, could be used for any function that the SP and IdP agreed were useful and allowable such as personalisation.