Forum Stats

  • 3,826,774 Users
  • 2,260,707 Discussions


SAML2 - Bug 33852475 Filed for APEX 21.2

Joe Upshaw
Joe Upshaw Member Posts: 962 Silver Badge

This post is just a community service so that everyone is aware of an issue with the way that APEX constructs its metadata.xml which can prevent successful "handshaking" with various iDp providers.

The Service Provider (application) and the Identity provider (iDP) have exchanged SAML metadata and then configured it in their respective systems. However, the iDP is returning an error:

ERROR: authn request destination verification failed for IdpEntity: cac-idp

It appears that the underlying cause of this error is that Oracle Apex is missing the Destination attribute in the SAML request. Per the spec, this is a required attribute when the requests are signed, i.e. AuthnRequestsSigned="true".

We engaged the Oracle support team to participate in a working session with us and we verified all of the configuration settings. They then then captured all the information needed and agreed that this as a bug (Bug 33852475).

They are currently working on a solution, under this bug reference, to to add the attribute “Destination” in the XML SAML metadata generated by Oracle Apex. The bug is now at status 80, i.e. coding is complete and the fix has been sent to QA.

I'm not sure who else might be affected by this but, thought it might be worthwhile to pass it along. Our iDP is hosted internally and is running on ForgeRock's OpenAM. However, we suspect this is probably affecting other providers as well.


@DARREN_J , @sbrennan, FYI



  • Joe Upshaw
    Joe Upshaw Member Posts: 962 Silver Badge
    edited Mar 16, 2022 1:35PM

    So, we got a fix for this issue in the latest patch release 5. This destination fix was corrected and we confirmed it.

    ...and it's broken again.

    The spec in the metadata.xml has the wrong SAML release reference. sigh

    This issue here is that the namesid-format:persistent has the wrong SAML spec.



    is supposed to be this:


    The persistent setting wasn't added until the SAML 2.0 specification. 

    This difference isn't merely pedantic. This mismatch causes the identity provider to reject the request with an HTTP 400 ("Bad Request") error. So, it is a complete show stopper for SAML integration.

    Opened a new SR for the issue.

  • Lai CC
    Lai CC Member Posts: 9 Blue Ribbon

    Thanks for heads up! The delivered SAML does not support message encryption. Hope it will be in future.

  • Joe Upshaw
    Joe Upshaw Member Posts: 962 Silver Badge

    So, the "fix" for this issue from Oracle support was to manually correct the SAML specification for the nameid-format:persistent attribute/value pair.

    From Oracle Support:


    While we agree that 2.0 should be the default and not 1.1 (hence logged an internal BUG), making that change in the code now could potentially lead to regressions with existing integrations.

    There is no reference to the NameID format in the AuthnRequest that APEX sends to the IdP and APEX currently does not verify the response's saml:Assertion/saml:Subject/saml:NameID/@Format. Currently, the only reference to the NameID format on the APEX side is in the metadata.

    You should modify the apex_authentication.saml_metadata.xml...

    This (the manual correction) did not fix the issue for us but, it did get us a step further I suppose. We are now running into this problem despite confirming that the SAML response is valid. From our new SR:

    Using APEX 21.2 update 5 to perform SAML authentication we are getting the error during the SAML Response phase. The error is "Invalid value for parameter: /Response/Signature".

    I successfully validated the response xml file using No errors were detected with either the signature or certificates as configured. At this point do not know how to debug the error.

    Hopefully, this running commentary will be helpful to others (or others know of a workaround!!!). One of the other bugs we found did help out others who were using Shibboleth IdP and they were able to get it going at least.


  • Lai CC
    Lai CC Member Posts: 9 Blue Ribbon

    Did you manage to get the metadata fixed?

    For me I just edit the generated metadata with desired nameidformat before manual registration on our ADFS IDP. It got a valid response from ADFS server but the nameid format field is missing from the response (with v1.1 emailaddress format)!! Going to try 2.0 persistent nameidformat.

  • Tae Lerch
    Tae Lerch Member Posts: 5 Green Ribbon

    I am seeing "Invalid value for parameter: /Response/Signature" as well. If I presume this to be an xpath expression then i can say that apex expects the signature to be a child of the response element. In our case it is not, instead we have a signature at /Response/Assertion/Signature. If it isn't an xpath expression then I'm just babbling nonsense.

    Our idp admin looked at what I presented to them and mentioned something about consulting with colleagues about setting up our sp such that they sign the response rather than the assertion. I haven't heard back from them yet.

    I've gone as far as setting up a Keycloak instance to act as a saml2 idp. I've setup a project to use it, but I have not set it up to test assertion vs response signing yet. Instead of doing useful productive things, I've been taking jaunts into reading the less obtuse sections of the saml specs... some of it is still very obtuse, mind.

    If nothing else, I feel ur pain. hopefully, I'll have more to share after the idp folks sort it out.

  • Tae Lerch
    Tae Lerch Member Posts: 5 Green Ribbon

    followup. tested vs keycloak. "invalid value for parameter: /Response/Signature" does indicate xpath, but it also covers validity of the signature. In debug messages, I went from:

    Could not find Signature for: URI="#ID_7643476d-be59-4502-852f-0c8c85317..."

    to (signature element is under the response)...

    Digest value for input is different:

    I've seen this explained in another post somewhere... I'll have to search the forum again. something about signature algorithms or a bug where spaces or crlf are introduced into the idp's key. I tried rsa-sha256 vs rsa-sha512 same result, so I don't think it's algorithm selection. perhaps this is where you are at too?

  • Joe Upshaw
    Joe Upshaw Member Posts: 962 Silver Badge

    Just a note that we had no less than Christian Neumueller himself work interactively with us to attempt to resolve the issue. He gave us a verification script to run which, unfortunately, didn't find the error but, rather, produced the "all happy" responses. So, we're waiting for what to try next.

    SQL> set serveroutput on
    SQL> @verify_3_29016743941.sql
    Procedure created.
    No errors.
    ok - Is samlp:Response
    ok - Same cert for assertion and response
    ok - Response verified
    ok - Assertion verified
    ok - Manipulated assertion NOT verified
    PL/SQL procedure successfully completed.

    Just a bit more info about our setup. We are using ForgeRock's AM v.6.5.3 as our iDP and we currently have about 700 federated applications that rely on it. We're also using this same iDP for federating authentication to our Oracle Cloud Infrastructure (OCI) tenancy. We, too, got it working on Shibboleth.


  • Lai CC
    Lai CC Member Posts: 9 Blue Ribbon

    I am still stuck at getting 'Responder' status code response from our MS ADFS IDP. Apex debug log will show no data found error when processing such response.

    From my observation, APEX insists on sending request with algo SHA512 but our IDP default to SHA256 in response. If I generate the authnrequest manually using samltool or java with SHA256, the status code in reply is Success but APEX throws error page without any log when processing such reply. Some how I think it has something to do with the signing algorithm.

  • Joe Upshaw
    Joe Upshaw Member Posts: 962 Silver Badge

    @Lai CC Do you have a way to manually sign it with SHA512? Have you tried that?

  • Lai CC
    Lai CC Member Posts: 9 Blue Ribbon
    edited May 6, 2022 5:42PM

    Yes i did tried to sign manually with sha512. Got back responder status. Checked with our adfs admin, the idp log says 512 not supported. So i know why its returning responder to apex. Apex also not able to parse sha256 success respond from our adfs idp as i have tried sending manually sha256 signed msg to idp.

    I tried to setup auth0 saml, got that invalid parameter value mentioned somewhere in earlier post. I think some idp may structure respond differently. Is it the saml standard too open for different implementation?

    If apex allows us to configure to sign req or parse reply with sha256 or 512, i think it will work.