SP is not redirecting to IdP SSO url


I have recently integrated Ping Federate idp SSO with my SP (vendor application). We have setup SP initiated SSO with all the details from IdP and SP. But somehow when we are trying to login SP site it is not redirecting to the IdP SSO url for authentication. Instead of which it is opening up the basic login page of SP itself.

Below logs were generated in security folder, which seems fine

08:23:47,488 LOGIN FEDERATED SECURITY ‘UseFederatedAuthentication’ setting is enabled. Automatically redirecting to configured identity provider. See saml configuration file for more information.

When checked no errors logs are being created.

But when we try to browse ACS url which we have provided to IdP as per verdor documentation, we get below error

08:16:50,530 ERROR APPLICATION Application error. [PAGE: /federatedsecurity/saml/signin | EXCEPTION: The message is not an HTTP POST. (Void ReceiveResponse(System.Web.HttpRequest, System.Xml.XmlElement ByRef, System.String ByRef), ComponentSpace.SAML2)]

Any help is appreciated to help which direction we should go to resolve this or is there anything which we are missing??

Make sure that the page where you initiate SSO doesn’t require the user to be logged in. You need to permit “unauthorized” users access to this page otherwise you’ll be redirected to the local login page.

The second error occurs because the ACS page is expecting to receive a SAML response in an HTTP Post. If you browse to the page (ie an HTTP Get), you’ll get the error you’re seeing.

Thanks for your response.
Got your point related to second error. But on the first one we have already enabled Anonymous authentication & disabled the basic & windows authentication. Is anything else we need to check to allow “unauthorized” access

That should be it.

I suggest checking the login URL in the browser’s address bar to confirm it has a ReturnUrl query string parameter indicating ASP.NET is redirecting as I suspect.

Also, you could use the browser developer tools to take a look at the network traffic to see exactly what’s happening.

See if there are any other pages that also require a local login when this wasn’t intended.

Thanks for your support. I was able to move forward and now the SP is redirecting to Idp provider and can see the SAML request being generated.

But now getting below error:

14:47:19,259 ERROR APPLICATION Application error. [PAGE: /federatedsecurity/saml/signin | EXCEPTION: An error SAML response status was received. urn:oasis:names:tc:SAML:2.0:status:Requester: Signature required (Void ProcessSAMLResponse(System.Xml.XmlElement, Boolean ByRef, System.String ByRef, ComponentSpace.SAML2.Assertions.SAMLAttribute[] ByRef), ComponentSpace.SAML2)]

Could you help to analyze the error, as checked the certificate of Idp & SP have same signature algorithm, thing else we can check??

The identity provider is returning a SAML response with an error status which appears to be indicating it requires the SAML authn request to be signed.

In your service provider’s saml.config, set the SignAuthnRequest flag to true for the <PartnerIdentityProvider> entry. This requires you to have configured a local certificate under your <ServiceProvider> entry.

If there’s still an issue, please enable SAML trace and send us the generated log file as an email attachment.

Thank you for your response.
When we are set the SignAuthnRequest flag to true & providing the local certificate details (we have provided pfx file in the web root folder & also tried the certificate store option by providing the License serial no. & license thumbprint but same issue) in the saml.config, we are again getting redirected to default login page.

And in error we are getting FEDERATED SECURITY An exception occured: Failed to generate signature.
From above scenario we can understand this is related to SP certificate, but can you help what can we check to resolve this issue.

Hi Team,
Thanks for your support i have found the resolution, issue is related to cryptographic service provider which we need to convert from type1 to type24.

Thanks for the update.