Granular authorization

As well as the ability for organizational 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 for all 80,000 members of the library. Rather than lose a sale, an SP might choose to sell them a license for only the 1000-strong physics department, so long as the IdP could pass an attribute that identified the users as 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 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, while not suitable for authorization, could be used for any function that the SP and IdP agreed were useful and allowable, such as personalization.