So, I see there are few different implementation profiles for SAML 2.0 sp-initiated configurations:
- POST-POST
- Redirect-POST
- Artifact-POST
- POST-Artifact
- Redirect-Artifact
- Artifact-Artifact
What are the advantages of each? We are implementing an sp-initiated approach and from an end-user perspective, the experience of each profile seems to be the same, but I’m concerned about the security implications. Is one more secure than the other?
BTW…We are implementing OpenAM as our IdP and SimpleSAMLphp as our SP library. If you know that setup will only support a specific profile, I’d love to know that too.
Security for all of the bindings are similar if implemented correctly. The main considerations are:
Redirect – may not be ideal for cases where a large message is being sent. Browsers have different limitations on maximum URL size. For something like an Authetication Reqest – it’s generally appropriate.
POST – better for large message sizes like Authentication Response. Most implementations use JavaScript to auto submit these. If your users are using modern browsers with JavaScript enabled you are probably ok.
Artifact – intended for old, typically mobile, browsers. What is sent via the browser is minimal – just a small random artifact used by the backend to resolve the SAML message. That said – it relies on your backend system being able to call out to the other party. Some network security architectures dont allow this.
Consult the SAML 2.0 Conformance doc for guidelines. For example Redirect is not allowed for the SSO response. Most commonly you will see Redirect-POST being used in deployments. I’m sure your chosen products will support these bindings.