Thursday, 28 February 2008

SAML Bindings Best Practices

The majority of SAML deployments we see are standardizing on the front-channel HTTP POST and HTTP Redirect bindings for SSO and SLO. These bindings are proving to be much simpler to implement than the bindings that require back channel communications.

Why is this?

The use of SAML bindings that require back channel communication (e.g. SAML Artifact and SAML SOAP bindings) are inherently more complex to deploy. We have masked a significant amount of this complexity within PingFederate but there are still a number of deployment considerations that always end up being tricky. Most obvious is the need to establish a secure direct communication path between the IdP and SP federation servers. This likely involves negotiating some transport level authentication mechanisms (above and beyond SAML message signatures), opening the appropriate firewall ports to allow requests/responses between servers, implementing proxy servers or web service gateways, again to allow connectivity through the DMZ, etc. This additional complexity comes without any real material advantages that make the extra complexity worthwhile.

For example, the Artifact Binding is no more or less secure than the POST Binding as it relates to message replay attacks. The main reason for the existence of the Artifact Binding was to actually have an option in SAML 1.x SSO where SP’s did not have to validate XML Digital Signatures over each SAML Assertion. The Artifact Binding allowed the signature to be optional, and instead allowed the deployer to leverage transport level security. It was felt that this offered a simpler implementation option for SP’s. The SOAP Binding was actually introduced as a performance optimization for SLO, as opposed to having an IdP redirect the browser to every SP to indicate a Logout had occurred. To leverage SOAP SLO each SP is required to track local user session state in some backend database so that the user session can be cancelled (logged out) without the browser being present. Common practice among SP’s seems to be to maintain user session state in a browser cookie which requires the browser to be present. As such SOAP SLO has seen very limited use.

New SAML deployments should take advantage of lessons learned from past experience and avoid the back channel bindings. It is much more likely that your federation project will run more smoothly if you do. This is also why we chose to target the front-channel bindings for Auto-Connect.

Posted by pharding at 11:30 AM in IdM | Responses (0) | Permalink

Thursday, 14 February 2008

PKI and SAML - Friends or Foes

One of the reasons that SAML based Federation exists is that wide-spread use of user certificates never materialized. If it had, then it is unlikely that SAML would be what it is today as user certificates themselves can securely solve the cross-domain web SSO problem.

That said, there have been some industries that have been willing to invest the money to make PKI work at scale for large user communities. As such we at Ping have struggled to justify the value of SAML in these entrenched PKI communities that already rely on user digital certificates for authentication and cross-domain web SSO.

We have been recently discussing with a number of these communities a security architecture where federation is useful in addition to user certificates. In this architecture SAML Assertions are used solely for authorization purposes rather than for the more generally accepted purpose of authentication/SSO. Their issue is that digital certificates are not well suited for conveying directory based attribute information, such as user role and group designations, that is used for making authorization decisions. These user attributes can change over relatively short periods of time. While they will continue to authenticate users and systems with certificates, they plan to leverage SAML Assertions to communicate user attributes between applications in different domains. These attributes will be used to make authorization decisions.

For example, if a user from Domain A turns up at an application in Domain B they will be authenticated by that application with their cert as usual. But the application in Domain B needs certain user attributes to make authorization decisions that are in the directory in Domain A. SAML Web SSO is used to request a SAML Assertion from Domain A that contains the necessary user attributes. The user will also be required to authenticate to Domain A with their certificate before the SAML Assertion is made available to Domain B.

This security architecture supports a decentralized identity infrastructure rather than requiring a centralized directory infrastructure. It also alleviates the need for directory synchronization between domains. While the back channel SAML Attribute Query/Response protocols could also be used for retrieving SAML Assertions, there are significantly greater deployment headaches associated with setting up SOAP based back channel bindings. The front channel, browser based POST/Redirect bindings are much simpler to deploy. The SAML Assertion and the attributes themselves are integrity protected via an XML Signature, and optionally can be kept confidential with the use of XML Encryption.

Posted by pharding at 7:51 AM in IdM | Responses (1) | Permalink