Geek Answers Handbook

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

I suggest using SAML 1.1 as a technology for checking Web SSO in a client environment, and they asked me something interesting:

Which script has a browser profile / POST, and which browser profile / SAML artifact scripts are appropriate?

In fact, the SAML 1.1 specifications do not talk about the best and most suitable scenario for both browser profiles.

Perhaps the security threats of each of them can be used to pick the best. In my vision, both options can be applied the same way in any scenario so far.

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

+4
source share
2 answers

It seemed to me that both profiles offer the same level of security. With a POST profile, the user must explicitly initiate a POST. This may help disrupt something in accordance with the CSRF attack, but I don't know any real exploits. An Artifact profile using the GET method can provide the user with a more seamless experience.

For me, the drawback of the Artifact profile is the difficulty of opening the return channel. My application server allocates a thread for processing a user request, and if this thread is blocked (waiting for the return channel I / O to complete) for a very long time, the application server starts to work very poorly. Thus, communication with the return channel must be done very carefully to ensure that it expires after a certain period of time.

Even then, if IdP does not work, it is not so obvious to my users that the error is in IdP. With a POST profile, if IdP behaves badly, users are less likely to blame me.

+3
source

In security terms, the main difference is that with the POST profile, the SAML response (containing the statement) moves through the end user's browser, so it MUST be at least signed and possibly encrypted if there is anything you would not like so that the end user can see.

With an artifact profile, you can use SSL to protect the reverse channel and send an unsigned, unencrypted statement, as it is transferred directly from IdP to SP. However, you can still sign a waiver to refuse.

As Erickson notes, although configuring the outbound “return channel” for connecting from SP to IdP has its own problems. Most SAML deployments I've seen use POST for this reason.

BTW - any reason why you are using SAML 1.1 rather than 2.0?

+2
source

More articles:


All Articles