SAML attributes vs. entitlements — a quick rule of thumb

One specific issue that came up during discussions at the FAM10 conference (see my previous post) was about the use of ‘attributes’ vs ‘entitlements’ in the SAML messages passed from Identity Providers to Service Providers’. For the purposes of this discussion:

• an attribute is some property of the individual — eye colour, age, sex and staff category being examples;
• an entitlement is an indication of something that the person is allowed to do once they have been authenticated.

(Note: in practice, both attributes and entitlements (as used here) are carried as SAML attributes — the difference lies only in their semantics).

In most use-cases it is possible to use either attributes or entitlements to achieve a particular task. For example, individuals with a staff category of ‘librarian’ (an attribute) may be inferred by the Service Provider to be allowed to order new books within, say, a library management system — anyone with that attribute is allowed to do so. Alternatively, a ‘bookOrdering’ entitlement may be used — only people with that entitlement are allowed to order new books, irrespective of whether they are a librarian or not.

So, the question arose, when does one use an attribute and when does one use an entitlement?

In the discussion, I proposed a rule of thumb for making that decision, as follows:

Where you specifically want to control access to some resource or function, and particularly where such a requirement exists across multiple Service Providers, use an entitlement. Where you want to record a property of an individual, particularly where that property issued across multiple Identity Providers, and where different Service Providers may take different actions based on that property (e.g. one system may use the property to configure the user interface, another may use it to control access) use an attribute.

Simples!

Well, not really, but it’s a start.

Originally published at efoundations.typepad.com on October 14, 2010.