Troubleshooting: SAML Integration Fails With a 405 Error When the IdP URL Has No Trailing Slash

Version Affected: All
 
 

Overview

A service-provider-initiated (SP-initiated) SAML integration fails before the user ever reaches the SecureAuth Identity Platform sign-in page. The service provider posts its SAML request to the realm, and Internet Information Services (IIS) rejects it with an HTTP 405 Method Not Allowed response, so the realm is never invoked and no error is written to the realm's own logs.

The symptom looks like a problem with the SAML configuration itself, even though the integration has been set up correctly at both ends, because the assertion never gets a chance to be issued. A browser SAML trace shows the POST leaving the service provider and the 405 coming straight back. The cause is that the IdP URL configured at the service provider has no trailing slash.
 

Cause

The identity provider (IdP) URL configured at the service provider is missing its trailing slash.

A SecureAuth realm is a directory in IIS, not a file. When a URL ends at the realm name with no trailing slash, IIS treats that final segment as a resource to be fetched rather than a directory to be served, and it will not accept a POST to it. The request is rejected with a 405 before any SecureAuth code runs, which is why nothing appears in the realm's logs.

A GET to the same URL usually succeeds, so you can paste the address into a browser, watch it load correctly, and still have the wrong value for SAML. That is the detail that makes this hard to spot: the URL looks verified.

Resolution

To resolve this:

1. In the service provider's SAML configuration, find the field holding the SecureAuth IdP URL. Depending on the vendor, this is called the IdP URL, the SSO URL, the Sign-In URL, or the Identity Provider Single Sign-On URL.
2. Check whether the value ends at the realm name with no trailing slash, for example, https://<idp-hostname>/SecureAuth<NN>.
3. Add the trailing slash so the value reads https://<idp-hostname>/SecureAuth<NN>/ and save the change at the service provider.
4. Retest the sign-in. The POST should now reach the realm, and the SecureAuth sign-in page should load.

Where the service provider needs the SP-initiated endpoint named explicitly rather than the realm root, use the full endpoint instead; it does not depend on directory handling:

https://<idp-hostname>/SecureAuth<NN>/SecureAuth.aspx

Correcting the URL clears the 405, but it will not necessarily complete the integration on its own. If a SAML trace taken afterwards shows the POST reaching the realm and the realm returning a 200 or a 302 while sign-in still fails, the 405 was masking a second fault, and the remaining problem is further along the flow. Check the realm's post-authentication redirect and confirm it is configured to use the HTTP POST binding rather than the HTTP Redirect binding. Then re-capture the trace and read the response from the service provider: the service provider itself may be rejecting the assertion for its own reasons.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.