APEX

Got beyond this particular error by adding the ALLOW_HASH_FUNCTIONS parameter in the listener configuration file and adding ,SH1 to the default value of SH256,SH384,SH512.
Now get an "Invalid value for parameter: /Response/Destination" error trying to authenticate because the AssertionConsumerService does not match the request URL. This is because we are using a proxy through Pulse Connect Secure and APEX appears to be generating the metadata dynamically. Wish there was a way in APEX to specify a static AssertionConsumerService in the metadata generated by apex_authentication.saml_metadata so that we could get it to match the request URL.

Hi Brad
Congrats on getting that far ! lol
I'm still trying to work out what to put in each of the fields in the INTERNAL workspace. I'm using Azure.
From https://yoursite.com/ords/apex_authentication.saml_metadata
have you taken the certificate from <ds:X509Certificate> and added -----BEGIN CERTIFICATE----- and END around it for the "Signing Certificate" field?
Also have you used the SSL cert that's on your website and extracted the certificate and the Private Key, then used in "APEX attributes" Certificate and Private Key fields?
Thanks
Darren
p.s. I made a change to the local ords listener that i use in Tomcat as instructed by Oracle...
https://community.oracle.com/tech/developers/discussion/4491414/missing-saml-sign-in-at-instance-and-app-level-for-apex-21-2

Hi Darren.
The settings in the internal workspace have two main sections: 1. APEX Attributes, which define how apex will encrypt the data sent to the IdP and 2. Identity Provider Attributes, which define how the IdP will sign the SAML assertion.
The IdP itself will have a setting that indicates which certificate is used to sign the assertion. You will need to copy/paste that certificate information into section 2.
On the Apex side, you will need to generate a certificate and private key (using openssl for example). Copy/paste those into section 1. Then, you will need to provide the IdP with the certificate only, which it will use to decrypt the data coming from Apex.

Darren:
Here is an update on our progress. BTW, Kellen and I are working on this together. We have everything working with our configuration with the exception of the location attribute for the AssertionConsumerService tag in the APEX metadata. We need for it to be https, but APEX only generates an http URL. If we had control over that in the APEX instance configuration, we would have it working. It does work, but we get a warning that the information returned from the apex_authentication.saml_callback function is not secure. I most browsers, you can choose the option to "send anyway".

Hi Brad and Kellen,
Thanks for the replies.
I have followed Kellen's instructions and I have SSO configured for Azure and both side have the necessary certificates.
How does Azure know which application it should validate the user against when APEX doesn't specify a client ID or anything specific? The SignIn, SignOut, Issuer part in APEX specify the TENANTID of Azure.
Thanks

Hi Brad,
Did you get SAML sign-in working? I have configured APEX and my IdP at this point but when I go to login I get the following error on return from the IdP. I can see from SAML trace that a SAML response from the IdP is returned from the IdP.
Looking at the apex debug attached, you can see that first issue encountered is

Signature: Could not find >>URI="#_7553f264d67c77dbd7f7cd9e0eb501e1"<<

I'm not sure what this means.
Debug Message Data.xlsx (5.58 KB)Any help or pointers would be greatly appreciated.
Thanks
Stephen

I have seen this "Signature: Could not find URI...." error when using SAML with IDCS and was solved by asking IDCS team to set for both Assertion and Response.

Im not sure if my error is the same as that one, but i have to wait for an apex 21.2 patch as Im facing a bug

Thanks @maggy-hdz-oracle and @darren-j I'll see what options are available on the IdP. I'm running an environment locally in docker instances so I have access to the IdP (WSO2 Identity Server).

Just an update on the issue I faced.
I checked the SignatureMethod and DigestMethod algorithms used in the Assertion from APEX. Note rsa-sha512
Upon checking the IdP settings on my local IdP (WSO2 IS) I noticed that the Response Signing Algorithm and Response Digest Algorithm were both set to rsa-sha1.
Once I changed these to rsa-sha512 I got past the Signature URI issue.
I'm now faced with this:
Invaid value for parameter: /Response which is showing in the browser. I'll use https://www.samltool.com/validate_response.php to check the response.
ahhh SAML ...

I wish this were more helpful but, we're struggling with it too and eagerly watching this thread for updates.

[Joe Upshaw](/ords/forums/user/Joe Upshaw) I'm back to Oracle errors with my attempts to get this working. I now have this error after sign-in to the IdP and returning to ../apex_authentication.saml_callback

Exception in "final_exception_handler":
Error Stack: ORA-30625: method dispatch on NULL SELF argument is disallowed
ORA-06512: at "APEX_210200.WWV_FLOW_XML_SECURITY", line 1126
ORA-06512: at "APEX_210200.WWV_FLOW_XML_SECURITY", line 1307
ORA-06512: at "APEX_210200.WWV_FLOW_AUTHENTICATION_SAML", line 462
ORA-06512: at "APEX_210200.WWV_FLOW_AUTHENTICATION_NATIVE", line 1268
ORA-06512: at "APEX_210200.WWV_FLOW_PLUGIN", line 3500
ORA-06512: at "APEX_210200.WWV_FLOW_PLUGIN", line 4097
ORA-06512: at "APEX_210200.WWV_FLOW_AUTHENTICATION", line 1688
Backtrace: ORA-06512: at "APEX_210200.WWV_FLOW_XML_SECURITY", line 1126
ORA-06512: at "APEX_210200.WWV_FLOW_XML_SECURITY", line 1307
ORA-06512: at "APEX_210200.WWV_FLOW_AUTHENTICATION_SAML", line 462
ORA-06512: at "APEX_210200.WWV_FLOW_AUTHENTICATION_NATIVE", line 1268
ORA-06512: at "APEX_210200.WWV_FLOW_PLUGIN", line 3500
ORA-06512: at "APEX_210200.WWV_FLOW_PLUGIN", line 4097
ORA-06512: at "APEX_210200.WWV_FLOW_AUTHENTICATION", line 1688
ORA-06512: at "APEX_210200.WWV_FLOW", line 2519

Using the SAML Chrome plugin I can see the SAML request/response to the IdP and returning to APEX but then crash with debug-id xxxx. I've now logged an SR with Oracle to see if they can help but my expectations are low
Where have you got to with your configuration and tests?

Update:
Oracle have come back to me saying that the symptoms/trace matched unpublished bug 33670264 which has been logged for the Azure IdP, I'm using WSO2 Identity Server. They have a fix for it and plan to release it as a patch set for Apex 21.2 soon but no release date yet.
In the meantime, I'm configuring a Shibboleth IdP locally to see if I can get that working.
Regards
Stephen

Yeah thats the same bug i'm waiting to get fixed:
ORA-06512: at "SYS.XMLTYPE", line 310.
Wait for patch 33420059 to include bug 33670264

The APEX 21.2.2 patch is available in Oracle Support

@darren-j I applied the patch to my environment this afternoon. I then went to adject the parameters for my WSO2 IS IdP because I had been testing with Shibboleth IdP. Entered the signing cert for the IdP and bang:
It's the same cert I was using the other day (head-banging-wall). Tried to update the database using APEX_INSTANCE_ADMIN.SET_PARAMETER to get some more details. Error is:
So, I'm no further along but would be interested to see how you get on.

I am now getting
Invalid value for parameter: /Response/Signature
<samlp:Response ID="
.....
</samlp:Response>
but haven't had time to look into it yet.

Update:
My issue from above was because my SSL cert had expired ... doh!
DARREN_J I've now got the same issue so I guess that's progress of sorts. My APEX debug shows
The first error says:

Digest value for input is different. Expected=boWoJD2NeRDymU5CeMYYR82gcjLIUMIstSuanmduhPwqliVeZ4gpedTeJLJetyUn4JrSnROpwJ2W
Q9obqeSU+Q==, Computed=boWoJD2NeRDymU5CeMYYR82gcjLIUMIstSuanmduhPwqliVeZ4gpedTeJLJetyUn4JrSnROpwJ2WQ9obqeSU+Q==

In the response the SignInfo DigestValue is:
rnFLdIju2J8Pr+QREPD0WuInbZvUQka3L7ukd/obhJRuOdIzqJoKRlF3RVtnmZJhTTR1I5DWZPH627srRviQVg==
and the Assertion SignedInfo Digest Value is:
bIzSEHqDbPuskhT6pigs0NADJR8jc07Q3Jaarmp2Z0oaiQr1XIfgG6Lc3ZB7+eJnmPAUK1DmzYcT7fPHS4zcSw==
I'll update my Oracle SR with these details.

Hi sbrennan
I've checked and rechecked my values but i can't see anything wrong.
When i go to my apex app:
https://my.company.com/ords/f?p=107
i have to login with my Azure username and password and then use MS Auth for 2FA. The log in is fine as the Azure Sign-in logs in Enterprise Application says "Success".
The return back into my app with
https://my.company.com/ords/apex_authentication.saml_callback
then returns

Invalid value for parameter: /Response/Signature

<samlp:Response ID="_57b2tr56-8f0d-4397-91a0-5r430c8d0397" Version="2.0" IssueInstant="2022-01-31T21:58:25.698Z" Destination="https://my.company.com/ords/apex_authentication.saml_callback"
.... 

I do not have any pointers to the problem apart from the Invalid value.
I'll have to create another SR !

Hi @darren-j
I got extra debug from APEX using the ..../apex/utilities/debug/d0.sql , d1.sql and d2.sql and posted it with my SR. Oracle are currently reviewing it. I suspect we have the same issue as I too get to my IdP, login and return to APEX where it fails with the same error. For info on running the debug see: https://chrisonoracle.wordpress.com/2020/04/03/debugging-apex-authentication-issues/
Stephen

Hi Stephen
Oracle replied to my SR and asked for the debug from the same link you gave above.
The reply was:
"In federation systems, the IdP has the ability to sign the entire response or just the assertion portion of the response (see screenshot below). Configure the IdP to sign only the assertion portion of the SAML response.
Reference:
https://confluence.atlassian.com/confkb/received-invalid-saml-response-signature-validation-failed-saml-response-rejected-938041884.html
"
Mine was already set to Assertion Only. Back with Oracle devs now.
Darren

Hi Darren,
I've heard nothing back from Oracle and I've provided them with full debug using the various scripts in the apex-installer/utilities/debug directory. I'll attached the debug here for comparison.
I'd love to know if anybody actually has this working and if so what IdP they are using just so that we'd have some hope in our attempts to get this working for our IdP's. I've tried Shibboleth IdP and WSO2 IdP and no joy. You're on Azure?.

DEBUG-10542.d2-10542.txt (350.08 KB)DEBUG-10543.d2-10543.txt (1.92 MB)Regards
Stephen

"I'd love to know if anybody actually has this working and if so what IdP they are using"
Anyone? C'mon, there must be someone somewhere! lol

Hi @sbrennan7 ,
I have received two instructions from Oracle in the last couple of days and now i can log in to Azure from APEX and return to the APEX page once logged in.

1. Although originally i was told the signing response was meant to be just "Assertion" the follow up from DEV was "APEX requires that BOTH the response and the assertion are signed." . I did this in Azure and got the same error on screen but the debug logs showed something new. On to point 2.
2. "This fails because the CipherValue is larger than 4000 bytes. Please ask the customer if they can disable XML message encryption: " I turned token encryption OFF in Azure.
   Now I can log in ok. I don't really know what implications turning token encryption OFF has.
   Hope this helps !
   Darren

Hi @darren-j
Thanks for the information :-) I tried disabling message encrytion but I've had no joy and I'm back to one of my original errors. I'll play around with it a little more and see where I land.
I expect Oracle to fix the CipherValue issue, surely disabling encryption of any sorts is not ideal - somebody from Oracle may want to enlighten us here.
Thanks again
Stephen

An update.
Oracle have responded to the error I've been getting:

Digest value for input is different. Expected=boWoJD2NeRDymU5CeMYYR82gcjLIUMIstSuanmduhPwqliVeZ4gpedTeJLJetyUn4JrSnROpwJ2W
Q9obqeSU+Q==, Computed=boWoJD2NeRDymU5CeMYYR82gcjLIUMIstSuanmduhPwqliVeZ4gpedTeJLJetyUn4JrSnROpwJ2WQ9obqeSU+Q==

with the following:
"Hi ,
The digest value in the XML response contains newlines, not the one that APEX generates on that system. A new BUG 33865318 - SAML AUTH: /RESPONSE/SIGNATURE ERROR WHEN XML DIGEST VALUE CONTAINS NEWLINES is filed to ignore newlines in a future version.
As a workaround, You should try using a signature algorithm that produces shorter digest values. APEX also supports SHA-256 and SHA-384, Please see https://www.w3.org/TR/xmldsig-core/#sec-SHA-256."
I'll try changing the signature algorithm later and update this thread ... it may be useful for other poor soul before they lose their sanity
Stephen

I also got a reply from Oracle Dev ref setting Token Encryption to FALSE:
"SSL security is independent of SAML encryption. SSL already encrypts data on the transport layer.
IMO SAML encryption is only relevant when a potentially untrusted or compromised third party could see the response. This could for example be the case in a micro services architecture, where assertions are being passed around from one service to the other. In APEX, the SAML response is not persisted, the information is only available in the apex_authentication.saml_callback request, or when system debug is enabled, then it gets stored in the debug tables. However, this information (username, group assignments, etc) is also available by other means in the application session data (e.g. the username in the APEX session).
I filed bug #33860635 because this should not result in errors, but do not see a security issue in this particular case."
Sounds like you are making progress Stephen. slow and steady ! Good luck.
Darren

I see a new patch available which notes a SAML fix. Will be deploying later this week to test.

# ----- NEW IN LATEST PATCH_VERSION: 5 -----
# 33845275 - SAML AUTH: AUTHNREQUEST SHOULD CONTAIN DESTINATION

https://updates.oracle.com/Orion/Services/download?type=readme&aru=24681162

We are applying it as I type this...
Drum Roll Please!

Any luck on your end?

@semone1 I'm planning to patch Apex early next week and I'll update this thread with the result - deep breath!

Sounds good @sbrennan7 . I'll let you know if I beat you to 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.
This:
SAML:1.1:nameid-format:persistent
is supposed to be this:
SAML:2.0:nameid-format:persistent
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.

Thanks for doing the needful. @joe-upshaw I'll cool my jets on our rollout.
edit: also I'm new to this world of Oracle SR's but if there is a way for me to add my voice to the need to get this working I'm happy to do so.

What IdP is everyone using?
Am I the only one to have this working? I'm using Azure.

We are (trying) to use our Shibboleth IdP.

We're using an ICAM that sits behind ForgeRock's OpenAM.

@darren-j
I've tested with Shibboleth IdP and WSO2 as we act as a service provider so our customer's could be using any SAML 2.0 compliant IdP including Azure. Good to know that it's actually working with Azure.
As a matter of interest Darren, now that you have it working, for the username attributes have you specified more than one? An IdP can release a number of attributes that are useful to us so I'm wondering if it is working or if it will prove to be another hurdle to jump.

An Update for anybody using Shibboleth IdP v4 as their Identity Provider. (semone )
Having applied patch 33420059: PSE BUNDLE FOR APEX 21.2 version 5 (21.2.5) which contains the fix:

33845275 - SAML AUTH: AUTHNREQUEST SHOULD CONTAIN DESTINATION

I can confirm that I have successfully authenticated with Shibboleth IdP.

Anybody using WSO2 - the latest patch has not fixed the issue I'm experiencing. I await a patch for the bug:
BUG 33865318 - SAML AUTH: /RESPONSE/SIGNATURE ERROR WHEN XML DIGEST VALUE CONTAINS NEWLINES
Hopefully the next patch version will have it

@sbrennan7 ,
We filed that bug. You're welcome ;-)
-Joe

@sbrennan7 ,
I'm not sure that 33865318 is really a bug. We've notice that Chrome puts in these extra spaces in signature and/or x.509 sections. I'm not sure any processor will simply ignore these. They actually aren't really present in the document but, when you try to save it down or view it, we see them. Other browsers, e.g. FireFox, are not demonstrating this behavior for us. So, we simply removed them manually.
-Joe

Hi I'm trying to finish our saml auth against Shibboleth. Pretty close now... saml_callback gives us an "Invalid value for parameter: /Response/Signature".
The debug message says: Could not find Signature for: URI="#_alphanumericString". the uri references an ID attribute in a saml2p:Response element/node. The signature is actually embedded in the assertion at /Response/Assertion/Signature ... rather than "/Response/Signature". --- I am interpreting that as XML_SECURITY.verify_signature expects the signature to be directly under the response element rather than its child assertion element?
If I've misinterpreted then I am at a loss for what is going on. If correct, then either I ask our security folks to configure the idp to put the signature under the response element (if possible), or I ask the apex team to look for the signature in the assertion? worth a 1000 words:

Hi,
I think you're seeing the issue I faced awhile back, see solution below, it's important that the digestMethod and signatureMethod algorithms in your IdP match what Apex is sending.
Stephen

thank you, I will chase that down. I thought I had aligned those, but my latest saml trace shows rsa-sha512 in the request, and the idp responds with rsa-sha256.

Hi Tae,
I am facing the same problem. Ms IDP respond only with sha256 but APEX 21.2.5 insist on using sha512.
Respond will always have 'Responder' in status. How can we change APEX to use sha256 instead of sha512?

I'm using Azure and APEX 21.2.6 (previously 21.2.2) and it works fine on both.
In my "Enterprise Applications" -> "SAML Based Sign On" I go to
SAML Signing Certificate and the Signing Algorithm can be SHA-1 or SHA-256
I'm using SHA-256.
I don't see any setting in APEX to choose strength.

Hi Darren,
What is the signature algo in the authnrequest and authnresponse message with Azure?
Are they both SHA256 or SHA512?

Still not fixed in patch 6. We had a one-on-one with a senior developer from Oracle. Will update once we find out more.
BTW, we are able to get this working with Shibboleth.
-Joe

Thanks Joe, I confirm that it is working with Shibboleth. We got ours working yesterday. Major points:
The idp must sign the response. our idp defaulted to (only) signing the assertion.
when supplying username attribute, you must supply the name and not the friendly name. I plugged in 'uid' instead of the 'urn:mace:bunchanbrs..' which you can ascertain by examining the response xml (if assertion and attributes aren't encrypted). ultimately we asked the idp to put our username in the Subject/NameId location so we accepted the default at the username attribute field.
As Darren stated, you cannot choose strength on the apex side, so Authn requests from sp to idp are at rsa-sha512. Our shib responds with rsa-sha256 (we are talking about digest encryption algorithm here). Request algo doesn't have to match response algo. Each side must be able to process or be configured for the appropriate algorithm. I briefly experimented with Keycloak as a saml IDP... when definining the sp in that idp, I had to indicate rsa512... so I suspect our shib team had to do something similar (or else shib detects and selects algorithm according to the request).
It should be noted that I don't run our idp, so I can only relay what they told me they did namely #1 above. They also had to put our username in the nameId field. Also note that we have not patched to 6 yet.
I just now looked back on page 1 of this thread and saw the #1 had an answer per Maggie. sigh. I'll go back and read the entire post to see what else I missed.