IDP SAML SSO initiated with HTTP POST request

[Duc Tran]

We have a custom assertion generator plugin (AGP) implemented for our outbound SAML SSO partners.  The flow is as follows:

 

1) User login to IDP web portal and clicks on IDP initiated SSO URL - - > /affwebservices/public/saml2sso?SPID=SP-entityname

2) SMFSS redirects the browser to the "Application URL"

3) Application URL (JSP page) receives user attributes along with SMPORTALSTATE and then POST back to:  /affwebservices/public/saml2sso?SPID=SP-entityname with the user attributes along with SMPORTALSTATE

4) SMFSS receives the POST and see that it contains SMPORTALSTATE so it will not redirect to Application URL this time and then passes the posted parameters to the custom AGP.

 

For troubleshooting and debugging purposes we want to be able to bypass the initial HTTP GET to - - >  /affwebservices/public/saml2sso?SPID=SP-entityidname to start the IDP initiated SSO, but instead we would like to just do an HTTP POST to:  /affwebservices/public/saml2sso with the user's attributes along with the provided SMPORTALSTATE and a valid SMSESSION cookie to the AGP.

 

When we tried this, we get a 400 error from the SMFSS.  Since the SMPORTALSTATE value is being passed, I would think that SMFSS would simply pass this on to the AGP to complete the IDP initiated SSO.  Am I missing something here?

 

ID: 3aa5d474-a41392a0-4ba21678-f8fa4aa2-631f8195-6 failed. Reason: UNSUPPORTED_AUTHN_REQUEST_BINDING

Attachment(s)

400 error flow.txt.zip   1 KB 1 version

successful idp initated flow.txt.zip   4 KB 1 version

[Joseph Rahme]

Hi Duc ,

 

can you please capture fiddler from both tests and send it to us ? would like to see the differences in your post .

Also did not see any mention of the SMPORTALURL , are you passing this at all ? 

 

Regards 

Joe 

[Duc Tran]

Hi Joe,

 

Thank you for your response.  No, I am not passing the SMPORTALURL in the POST because I don't see that value being passed in the original flow.  Instead of a Fiddler trace, I originally attached two FWTrace.log files which captures two attempts, one is for the existing flow that works and another is for the new flow that I am trying which fails.

 

Please let me know if you need to get more info.

 

Thanks!

[Peter Burant]

This appears to be a configuration issue:

 

[07/19/2018][21:45:21][7250][2928671632][3aa5d474-a41392a0-4ba21678-f8fa4aa2-631f8195-6][SSO.java][processRequest][Request received on POST but POST not enabled.]

 

Reconfiguring the partnership (or SP object if Legacy) to allow authnrequest via POST should allow the request to proceed.