Convenient applications for Browser/POST and Browser/Artifact SAML profiles

Question

I'm proposing the use of SAML 1.1 as technology to prove Web SSO in a customer environment, and they asked me something interesting:

Which scenario Browser/POST profile is appropriate, and which scenarios Browser/Artifact profile of SAML is appropriate?

In fact, SAML 1.1 Specifications don´t talk about the best neither most appropriate scenario for both Browser profiles.

Maybe security threats of each one can be used to pick up the best. In my vision, both can be applyed equally in any scenario so far.

*Note: The solution uses Weblogic Server 10.0 and its support to SAML 1.1.

Answer 1

It seemed to me that both profiles offer similar levels of security. With the POST profile, the user has to explicitly initiate the POST. This might help to thwart something along the lines of a CSRF attack, but I don't know of any actual exploits. The Artifact profile, with its use of the GET method, can provide a more seamless experience for the user.

For me, the drawback to the Artifact profile is the complexity in opening the back channel. My application server dedicates a thread to handling the user request, and if that thread is blocked (waiting for the back-channel IO to complete) for very long, the app server begins to perform very poorly. So, the back-channel communication has to be performed very carefully to ensure that it times out after a defined period of time.

Even then, if the IdP is down having trouble, it's not as obvious to my users that the fault is at the IdP. With a POST profile, if the IdP is misbehaving, users are less likely to blame me.

Answer 2

In terms of security, the main difference is that, with POST profile, the SAML response (containing the assertion) travels via the end-user's browser, so it MUST be at least signed, and possibly encrypted, if there's anything you wouldn't want the end-user to be able to see.

With the artifact profile, you can use SSL to secure the back-channel and send an unsigned, unencrypted assertion, since it is passed directly from the IdP to the SP. You may still want to sign the assertion for non-repudiation, though.

As Erickson mentions, though, setting up the outbound 'back-channel' connection from the SP to the IdP comes with its own challenges. Most SAML deployments I've seen use POST for this reason.

BTW - any reason you're using SAML 1.1 rather than 2.0?