The common configuration for SSO Authentication Binding is HTTP-Redirect (redirect to http://server.domain/affwebservices/public/saml2sso with SAMLRequest query parameter).
But this poses a problem when your SAMLRequest is huge.
So, customer would like to use POST method for SSO Binding.
Here is a quick sample on how things will work.
First, the configuration: This is assuming you are using CA SSO for both IDP and SP.
In this sample, both the IDP and SP are running on the same machine so I have created the entities as below.
For IDP (Entity Name):
Local SAML2 IDP: idp (EntityID is idp)
Remote SAML2 SP: sp (EntityID is sp)
For SP (Entity Name):
Local SAML2 SP: sp2 (EntityID is sp)
Remote SAML2 IDP: idp2 (EntityID is idp)
And the Partnerships are created as below.
There are 2 Partnerships created as both are running on the same box.
idp2sp Partnership is configured as below.
And the sp2idp Partnership is configured as below.
To note, I have configured AuthnRequest to be signed.
Now, when you make an AuthnRequest(SP Initiated) request by visiting "http://www.partner.lab/affwebservices/public/saml2authenrequest?ProviderID=idp" you will find the POST request going to "http://www.sso.lab/affwebservices/public/saml2sso"
To let you know the requirement for SSO POST Binding, you must configure a Session Server.
If you are familiar with CA SSO(SiteMinder), you would know about Post Preservation.
That is when you POST a data to a protected site without a valid session.
The target agent protecting the resource will preserve the POSTDATA and POST the encrypted POSTDATA to the login page.
The POST method must continue(even when you have a cookieprovider) and the same POST request must be replayed at the target after getting a valid session.
But /affwebservices/public/saml2sso is NOT a protected resource.
What happens is, the POST data is stored in the Session Server and the GUID to reference the data will be set as a cookie(cookie name is GUID).
Then the browser is HTTP 302 redirected to the AuthenticationURL(/siteminderagent/redirectjsp/redirect.jsp) which is protected.
And again HTPT 302 redirect to the login page.
So, this redirect continues until you are redirected back to saml2sso and it would be a GET request instead of POST.
Now that the request was a GET but it carries GUID cookie which has reference to the SAMLDATA stored in the Session Server so that gets called and the processing continues.
Following is a screenshot where AuthnRequest was made and redirected to the login page.
You can see in frame #4 where there is a POST to IDP's saml2sso application.
POST http://www.sso.lab/affwebservices/public/saml2sso HTTP/1.1
Accept: image/jpeg, image/gif, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET4.0C; .NET4.0E; .NET CLR 3.5.30729; .NET CLR 3.0.30729)
Accept-Encoding: gzip, deflate
If you look at the POSTDATA, it has the following.
And the Response is as below.
The GUID cookie is being set and the value is actually same as the TransactionID for this request.
So, if you look for this GUID value (minus the leading "1:" ) you will find matching transactions in the log.
I am attaching "IDP_FWSTrace.log" matching the above transaction and the "samplePOST.saz" fiddler trace sample for your reference.
They are in the "samplefiles.zip" file.