XACML w/ OpenID Connect, SAML, OAuth and SCIM

|

At the end of Paul Madsen's presentation at CIS a couple weeks ago, he ended with a question that he also posed on Twitter:

tweet

The integration of SAML, OAuth, OpenID Connect, SCIM, and other neosecurity standards are relatively straightforward. The fly in the ointment though is XACML. How does it fit w/ all these other security specs? Matt Topper offered his thoughts in reply to Paul's tweet:

tweet

When I borrowed a similar deck from Paul for a recent presentation in London, I left off w/ the same question. I was followed that day by David Brossard, VP of Product Management at Axiomatics, a company specializing in XACML who we've since partnered w/. Him and I talked about Matt's point in the blogosphere a couple years ago and discussed these things more that day. After all these conversations and time, let me try to summarize my current thinking on how XACML integrates with protocols like SAML, OAuth, and OpenID Connect.

Integrating XACML into the Neosecurity Suite

To control access to cloud services and other federated apps, centralized policies can be defined in XACML that allow or disallow their usage. This is done by combining XACML with a federation protocol (e.g., SAML, OpenID Connect, etc.). When a user tries to access a cloud service or other app using Web SSO, a federation server needs to mint a security token which the Service Provider (SP) will use to identify the incoming user. Before creating this token, the federation server can call out to an authorization server (the PDP) to check these centralized rules. Based on the answer back, instead of blindly allowing the unauthorized user to gain access to the cloud, it may direct them to request the necessary privileges by executing a workflow. On the other side of the federation, the SP can also use XACML to control access. As I mentioned in my tweet to Matt, this can be done by calling out to the PDP and including the incoming token. The digital signature of the token can be checked by the PDP, and, if valid, it can extract the user attributes from the message. In this way, the SP has a high degree of confidence about the asserted user attribute without embedding entitlement rules in the federation server or the application. This architecture is shown in the following sketch:

XACML with a federation server

This scenario can be implemented today using existing products like PingFederate and Axiomatics Policy Server (which we resell from our partners).

Considering the novelty of SCIM, however, it's not surprising that its possible usages with XACML are still gelling. One way the two may eventually work together is to provision entitlements policies associated with users and groups to other domains. This would allow enterprises to extend their on-premises authorization solutions to the cloud, but it may require changes to SCIM like the ones I proposed. These were based on conversations a number of us had in Paris at the IETF meeting and at IIW in San Francisco, so it's possible but, in no way certain, that they'll be included in the final IETF spec. Even still, I now realize after chatting w/ David that more is needed. XACML policies are not user- or group-specific; they are defined at an organizational level. After talking w/ the editor of the SCIM 1.0 spec, Trey Drake, I think what might be best is to create a new top-level entity in SCIM called Policies, e.g. This would allow clients to created and managed organization-wide authorization policies by sending SCIM messages that include an encoded version of the XACML rules to this new endpoint. Then, cloud service providers could store and enforce these policies even though defined elsewhere by their enterprise customers. This would be a massive step forward for the cloud, and we at Twobo are working hard w/ the vendors and the community to make this usage scenario as easy to implement as the previous one.

This post is getting too long to go into how XACML and OAuth can be used together. I already promised a post on the importance of OAuth, so I'll touch on both in an upcoming entry. In the meantime, please let us know how you see XACML fitting or not fitting w/ the neosecurity specs by posting a comment here or on Twitter. Also, if you have deeper questions, feel free to contact us. Please join the SCIM community as well, and share your thoughts with the group.

Comments