Identity Provider requests ACS through Redirect not POST

[nevsie]

The IDP is having trouble when signing is true for either or both assertion and response. They are working their end on the problem, but have requested that we "change the binding of the request change from POST to Redirect." I assume they are referring to ACS Login, as seen in META Data below... But I find no way to change this, control this, or even if it is the right thing to do and secure.

I have read that the login request is typically done via redirect, so not sure why POST would be used, as such, there must be a reason. Hence this request.

Thanks, N

[dsmrt]

I sounds like the IdP that you are working with wants the request/AuthnRequest (when you start on the craft site and are sent to the Identity Provider's site for login, aka SP Initiated login) sent with the redirect binding instead of the post binding.

If this is the case, their metadata must have a post binding in their metadata. Look for SingleSignOnService which will look like this:

        <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://example.com/sso" />
        <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://example.com/sso"/>

If you remove the HTTP-POST binding in the file and then re-save it in the Craft saml-sp plugin, the plugin will be forced to use the Redirect option.

I hope this fixes the issue! Let me know if you need more help.

[nevsie]

Hi, and yes. Both post and redirect are options. And yes that makes sense. I'll give it a try. Thanks. N

[nevsie]

Hi dsmart, As in the screen shots above, the IDP is on redirect, as expected. But the SP does not change or update when the META is changed on the IDP?

I modified the XML, and and saved IDP, then saved again the SP. Have I missed a step or need to clear something else?

Thanks, N

[dsmrt]

SP metadata doesn’t have to change because the SP (craft side/our plugin supports receiving both redirect and post bindings. If I understand the issue correctly, modifying the IdP metadata is all that is needed.

[nevsie]

Hi And thanks. It is more likely my understanding. To quote the query I received:

Please can you check the binding of the request, and if it is an HTTP POST, can you please change it to an HTTP redirect? We think this is what’s causing the SAMLRequest to not show up in the return URL, which is causing issues.

Based on my screen shots above, I only have one POST, and that is on the SP, ACS - therefore, I assumed this is used as the original request to the Idp, and the one they want to change?

My understanding is limited, but based on my reading: (no reason why it cannot be a POST, but it normally is a Redirect) SP sends a SAML authentication request to IdP. This can be done using a HTTP-Redirect 302 or 303.

So!!! Am I completely wrong and confused!!! Is the query I am being sent nonsense? Or did I set something up wrong? And, thank you for your support, it is appreciated.