This article provides a couple of troubleshooting steps to consider if, after enabling Signed Requests for Custom Security Assertion Markup Language (SAML) applications, the integration is not handling a Service Provider-initiated flow. 

• Custom SAML application
• Single Sign On
• Signed Requests enabled
• Service Provider must support Signed Requests

There are two possible causes for this issue:

• A missing attribute in the SAML Request
• A misconfiguration in the metadata provided by Okta

Include the Format attribute on the NameIdPolicy node. The Format value has to match the configuration for the application in Okta.

1. Navigate to Applications > Applications and choose the desired application.
2. Click on General > Edit (SAML Settings) and scroll to the bottom until the Preview the SAML Assertion button is seen.
    

   <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">

3. Click Next.
4. When using ComponentSpace, the Format cannot be set prior to calling InitiateSsoAsync.  This can only be set when the OnAuthnRequestCreated event occurs.

   _samlServiceProvider.Events.OnAuthnRequestCreated += (context, request) =>
   {
       request.NameIDPolicy.Format = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified";
       return request;
   };

If the issue still persists, follow the steps below.

1. Navigate to Custom App > Sign On.
2. Click on SAML Signing Certificates > Active Certificate > Actions > View IdP metadata. 
3. Set WantAuthnRequestsSigned to true manually (using any text editor).
4. Insert the updated metadata in the corresponding IdP metadata field (on the Service Provider side). 

Related References

• Application Integration Wizard SAML field reference
• How to Download the IdP Metadata and SAML Signing Certificates for a SAML App Integration