ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

SAML2AuthNRequest HTTP-POST binding

book

Article ID: 145798

calendar_today

Updated On:

Products

CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On Agents (SiteMinder) CA Single Sign On Federation (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) SITEMINDER

Issue/Introduction


We're running a Web Agent Option Pack and we'd like to know 


- How to configure the SP side in order to have the SAMLRequest POSTed
  to IDP instead of a GET through 302 redirect ?

Environment


Policy Server 12.7 on RHEL 6;

Web Agent on Apache 2.4 on RHEL;
Web Agent Option Pack on Tomcat 7.x, on;
IdP on IBM Tivoli;

Resolution


As you configured Legacy Federation - setup SAML 2.0 Auth Scheme,

HTTP-POST binding will NOT be an option. This has been a product
limitation for a long time regarding Legacy Federation feature itself.

However, Siteminder also has another Federation model, called
Partnership, which does support HTTP-POST bindings.

If IDP is also Siteminder, then IDP must meet the following
requirement.

  Enable SAML 2.0 HTTP-POST Binding

   "Important! Before you configure the authentication request binding,
    enable the session store. For the IdP to handle an authentication
    request that is delivered using HTTP-POST binding, the IdP must store
    the request in the session."

  https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-identity-and-access-management/single-sign-on/12-7/configuring/partnership-federation/saml-2-0-only-configurable-features/enable-saml-2-0-http-post-binding.html

Notice the difference between Partnership Federation and Legacy
Federation models is that, Legacy Federation is tightly combined with
smsession security protection, as Partnership Federation is less
integrated with security protection and more focused on Federation
features.

Please see details at:

  Implementing Federation in Your Enterprise

    CA Single Sign-On Federation has two deployment models:

    Partnership Federation

    Partnership federation is based on configuring partnerships between
    enterprises based on federation standards. The partnership model does
    not require configuration of CA Single Sign-On-specific objects, such
    as domains, realms, and policies. This model is recommended for new
    configurations using CA Single Sign-On Federation.

    Legacy Federation

    Legacy Federation (formerly Federation Security Services).

    Legacy federation is based on configuring CA Single Sign-On objects,
    such as affiliate domains, authentication schemes, and policies to
    protect federated resources. This model is primarily for backward
    compatibility with older deployments.

  https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-identity-and-access-management/single-sign-on/12-7/implementing/implementing-federation-in-your-enterprise.html