SungHoon_Kim

Sample SAML2.0 Federation using POST method for SSO Authentication Binding

Blog Post created by SungHoon_Kim Employee on Mar 16, 2016

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.

index.png

 

And the sp2idp Partnership is configured as below.

sp2idp2.png

 

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.

 

Request

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, */*

Referer: http://www.partner.lab/affwebservices/public/saml2authnrequest?ProviderID=idp

Accept-Language: en-US

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)

Content-Type: application/x-www-form-urlencoded

Accept-Encoding: gzip, deflate

Connection: Keep-Alive

Content-Length: 2861

DNT: 1

Host: www.sso.lab

Pragma: no-cache

 

ForceAuthn=false&IsPassive=false&SAMLRequest=PEF1dGh<TRIMMED>&Oid=21-7dbd8f60-d540-468a-bc2e-6d6f0810eb64&RelayState=49f7dcd0e68307e51528596923536a2c1a337486

 

If you look at the POSTDATA, it has the following.

ForceAuthn=false

IsPassive=false

SAMLRequest=XXXXXXXX

Oid=21-7dbd8f60-d540-468a-bc2e-6d6f0810eb64

RelayState=49f7dcd0e68307e51528596923536a2c1a337486

 

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.

Response

HTTP/1.1 302 Moved temporarily

Content-Type: text/xml

Location: http://www.sso.lab/affwebservices/redirectjsp/redirect.jsp?SMPORTALURL=http%3A%2F%2Fwww.sso.lab%2Faffwebservices%2Fpublic%2Fsaml2sso&SAMLTRANSACTIONID=1520386c-5ac406e5-0130cd24-96b979ec-3db0303d-0710

Server: Microsoft-IIS/7.5

X-Powered-By: ServletExec/6.0, Servlet/2.5, JSP/2.1

Set-Cookie: GUID=1:2302ab97-b89c424d-e824fc5c-9f983898-e2b51615-9c9; expires=Wed, 16-Mar-2016 06:09:28 GMT; path=/; domain=.sso.lab

X-Powered-By: ASP.NET

Date: Wed, 16 Mar 2016 06:06:28 GMT

Connection: close

Content-Length: 511

 

<html><head><title>Redirection</title></head><body>The document has been moved to <a href='http://www.sso.lab/affwebservices/redirectjsp/redirect.jsp?SMPORTALURL=http%3A%2F%2Fwww.sso.lab%2Faffwebservices%2Fpublic%2Fsaml2sso&SAMLTRANSACTIONID=1520386c-5ac406e5-0130cd24-96b979ec-3db0303d-0710'>http://www.sso.lab/affwebservices/redirectjsp/redirect.jsp?SMPORTALURL=http%3A%2F%2Fwww.sso.lab%2Faffwebservices%2Fpublic%2Fsaml2sso&SAMLTRANSACTIONID=1520386c-5ac406e5-0130cd24-96b979ec-3db0303d-0710</a></body></html>

 

 

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.

Attachments

Outcomes