SAML group attributes, SCIM and shortcomings

The goals are to have an article to point to, to illustrate to people when SAML (Security Assertion Markup Language) group attributes are sufficient and when SCIM (System for Cross-domain Identity Management) is also required to achieve security needs.

Intro

Most service providers are now supporting SSO (Single Sign-On). This is great to see as managing onboarding and offboarding in an enterprise context is very challenging without it.

However, this only covers authentication, if you want to do anything with authorization you need to do one of the following:

1. Define permissions for a given identity in the Service Provider (SP), this obviously does not scale well for centralized administration of an enterprise.
2. Pass group/permission details as attributes in the SAML AuthN response. I will discuss this here and what scenarios it is fine for and what it is not.
3. Use something such as SCIM to synchronize groups and permissions between your centralized administration and the service-provider. I will cover what scenarios this uniquely helps with, and also some pitfalls with lack of specification definition.

SAML AuthN Response attributes

WARNING, there is no such thing as “SAML Group Attributes”¹ in the specification. Essentially you can pass attributes, but need the Identity Provider (IdP) and SP to know what that format looks like ahead of time, below is an illustration of what you might receive in the SAML AuthN Response as the SP:

<saml2:Attribute Name="groups" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
    <saml2:AttributeValue>Developer</saml2:AttributeValue>
    <saml2:AttributeValue>Billing-Admin</saml2:AttributeValue>
</saml2:Attribute>

This can work in a scenario where you’re only doing user auth management in the UI, i.e they’re the agent that initiates contact with the SP and the SP does not allow for any delegate auth to represent them in a machine-to-machine context, such as an API key.

If you are fortunate enough to have a scenario supporting this there are other challenges with this “ad-hoc” approach in that you don’t know what permissions/roles/groups are available in the SP without some other API support. For security in the ideal case the SP fails-closed and if nothing maps correctly the user gets some base level authZ and not admin! But this is up to the SP and not defined as a requirement in SAML itself.

SCIM

First thing to remember is SCIM² is a push-based protocol. There are some providers (check this) that provide an API to check for the events instead, however there are no guarantees that the data is up-to-date. The key thing to remember with SCIM is it’s not easy to discern the difference between “no user attributes have changed” and “not receiving updates correctly for the user”, there is no concept of a “heartbeat”. The “freshness” property does seem like a large security hole that should have been a focal point of the protocol design.

I think having a heartbeat/freshness policy in SCIM would be ideal, whereby the IdP could say “if you don’t hear from me in by this time, do this with the user”, then there is no ambiguity on the sync delays.

There are a number of other variances between SCIM providers in how they request a user entity to be deleted, ranging from “please deactivate but retain the data” (soft-delete) to “remove everything” (hard-delete), to unspecified behavior in the middle.

API Keys

Here is something worth calling out with these two approaches. If you want to have the concept of an API key that is mapped to a user’s capabilities as defined in the IdP you absolutely must use SCIM! Otherwise if the user infrequently logs into the SP to propagate the group attributes to you the capabilities of the API key could become dangerously stale over time. You will still have the lack of heartbeat issues, but at least you won’t be utterly decoupled.

A New Hope?

A more modern approach appears to be coming from the OpenID Shared Signals Working Group through something called “Continual Access Evaluation Profile”³, which appears to have a primary focus around AuthN consistency in the SP, but it could have potential to also address stale AuthZ as discussed in this post.

Footnotes

• Sharing Options
• Toot
• Add to Pocket
• Submit to Reddit
• Share on LinkedIn
• Share on LinkedIn