Copy link to clipboard
Copied
I have an ADFS server acting as the IDP,
CF2021 update 5 using a simple SP setup running on RHEL 8/httpd.
Oracle JDK 11.0.17, SELinux is disabled. Signing and Encryption are disabled on the SP.
SSO was working until I created a security sandbox around the code webroot.
I created a default security sandbox around the web root, I started getting this error message: "Invalid SAML Response. Not match the saml-schema-protocol-2.0.xsd"
I enabled all Tags and Functions, "Other", and opened up the File/Folder permissions to absolutely everything, but it still fails.
If I remove the security sandbox, it starts working again.
coldfusion-out.log shows this:
01/31 10:26:40 [ajp-nio-127.0.0.1-8020-exec-3] WARN Error executing validateXML: schema_reference.4: Failed to read schema document 'bundle://5a95f7f4-292b-4044-9e7d-2bd1e4eb78ed_272.0:1/schemas/saml-schema-protocol-2.0.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.
org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema document 'bundle://5a95f7f4-292b-4044-9e7d-2bd1e4eb78ed_272.0:1/schemas/saml-schema-protocol-2.0.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.
at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) ~[xercesImpl.jar:?]
Copy link to clipboard
Copied
I have discovered a troubling Sandbox Security issue, which I wish to share with you. Though I am on CF2021 Update 6 + Windows 10 Pro + JDK 11.0.18, the issue might still be related to what you are experiencing.
I tested by enabling Sandbox Security in the ColdFusion Administrator, but without specifying a directory or file. The result was that ColdFusion would not restart.
When I looked at the logs, I saw SEVERE errors, such as the following, in coldfusion-error.log:
Apr 23, 2023 5:46:33 PM org.apache.catalina.core.ApplicationContext log
SEVERE: Servlet.init() for servlet [PMSGenericServlet] threw exception
java.security.AccessControlException: access denied ("java.io.FilePermission" "C:\ColdFusion2021\cfusion\wwwroot" "read")
at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.base/java.security.AccessController.checkPermission(AccessController.java:897)
at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
at java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:661)
at java.base/java.io.File.exists(File.java:826)
...
...
Apr 23, 2023 5:46:33 PM org.apache.catalina.core.StandardContext loadOnStartup
SEVERE: Servlet [PMSGenericServlet] in web application [] threw load() exception
java.security.AccessControlException: access denied ("java.io.FilePermission" "C:\ColdFusion2021\cfusion\wwwroot" "read")
at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.base/java.security.AccessController.checkPermission(AccessController.java:897)
at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
at java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:661)
at java.base/java.io.File.exists(File.java:826)
...
...
Apr 23, 2023 5:46:33 PM org.apache.catalina.core.ApplicationContext log
SEVERE: Servlet.init() for servlet [CFSecurityAnalyzerServlet] threw exception
java.security.AccessControlException: access denied ("java.io.FilePermission" "C:\ColdFusion2021\cfusion\wwwroot" "read")
at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.base/java.security.AccessController.checkPermission(AccessController.java:897)
at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
at java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:661)
at java.base/java.io.File.exists(File.java:826)
...
...
When I compared /lib/neo-security.xml with the back-up copy, /lib/neo-security.bak, I noticed a single difference. Namely in the element sbs.security.enabled.
Before the change: <var name='sbs.security.enabled'><boolean value='false'/></var>
After the change: <var name='sbs.security.enabled'><boolean value='true'/></var>
When I reverted to the file with 'false', I was then able restart ColdFusion without any problem. I wonder whether this is a bug.
In any case, the moral is clear. If you enabled Sandbox Security without specifying a directory or file to be sandboxed, there might be severe security errors.
Copy link to clipboard
Copied
Looking at it from another angle, does the following code run successfully?
Before the Sandbox Security change and after?
<cfscript>
adminPermissionObject=createobject("java","org.osgi.framework.AdminPermission");
writedump(AdminPermissionObject);
</cfscript>
Copy link to clipboard
Copied
I am unsure what the purpose of this test would be; the issue I'm reporting is regarding the new SAML plugin only.
In the course of my testing, I could find no combination of permissions that would allow the SAML plugin to work properly, even if all permissions to all filesystems were opened up.
My SSO issue appears to be an issue where the sandbox is preventing the SAML code from performing a schema check on an XML file using an XSD file that's stored within a JAR file (and accessible only via a URL)
Copy link to clipboard
Copied
This does not seem like a bug to me.
If you don't provide a whitelist to the sandbox, you have told CF that there are no folders it can read (or write, or apply CF code to). The "No read access" would appear to be an appropriate error message for the configuration.
However, the Admin UI probably should have done at least a minimal check to make certain that the syntax contains a valid directory or at least a string with a length greater than 0.
Copy link to clipboard
Copied
I thought you are dealing with a problem of forbidden access in a Security Sandbox. That is, of permissions. On looking further, that is probably not the case.
A new idea. I now suspect your XML or XSD may be invalid, in the wrong location or missing. If so, then ColdFusion would tell you where it had looked for the file path or URL. Does the following line of code confirm this?
/www/boris/wwwroot/nch/Application.cfc:80
Copy link to clipboard
Copied
When I disable security sandboxes on the web root, it works.
If I enable security sandboxes. It does not work. If I enable security sandboxes and open up all permissions across the entire system, including all possible file locations and paths, it does not work.
A missing file would not work regardless of the sandbox. If the sandbox was blocking a file from being read, then my second test should have been enough to get SSO working again.
That being said, the Application.cfc file does not contain references to any files outside of the webroot. The ColdFusion SAML implementation does not provide any ability to change anything beyond the basic metadata information for IDPs and SPs. More complicated configuration is not possible.
Finally, the missing file is noted in the error statement, but I'm pretty sure that would be considered an invalid path since it is not a physical filename, but probably an object in the java heap.
bundle://5a95f7f4-292b-4044-9e7d-2bd1e4eb78ed_272.0:1/schemas/saml-schema-protocol-2.0.xsd
Copy link to clipboard
Copied
I am surprised when you say that a missing file wouldn't work. The idea of a missing file isn't mine. I was just repeating part of the error message. It alerts us to the possibility that a process
"could not find the document"
The way I see it, the only way this could be user-related is if you yourself introduced XML processing into the mix. Which is why I asked what was happening on the line
/www/boris/wwwroot/nch/Application.cfc:80
Let's assume this is a system error. Firstly, let's rule out, as culprit, the change in XML behaviour in CF2021 Update 5.
Does that help?
If not, then the error is likely caused by a bug in the SAML implementation. The Apache Xerces libraries in the system may not be playing well with the Java version that ColdFusion is using. A clue is the bundle:// path, which is identified by a Java-generated UUID (5a95f7f4-292b-4044-9e7d-2bd1e4eb78ed).
From the error messages
Failed to read schema document 'bundle://5a95f7f4-292b-4044-9e7d-2bd1e4eb78ed_272.0:1/schemas/saml-schema-protocol-2.0.xsd
...
...
Caused by: java.net.MalformedURLException: access denied ("org.osgi.framework.AdminPermission" "(id=272)" "resolve,resource")
at java.net.URL.<init>(URL.java:679) ~[?:?]
...
...
Caused by: java.security.AccessControlException: access denied ("org.osgi.framework.AdminPermission" "(id=272)" "resolve,resource")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) ~[?:?]
...
...
my guess is that
In this case, I think you should report a bug.
In the meantime, you could try what someone else did when they had "Invalid SAML Response. Not match the saml-schema-protocol-2.0.x.... They resolved it by adding the following flags to the JVM arguments:
-Djavax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema=com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory
-Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl
Copy link to clipboard
Copied
I do appreciate your replies and your assistance in this. It was confirmed as a bug by Adobe a while ago. (https://tracker.adobe.com/#/view/CF-4217161)
The code at the line in question is this:
response = processSAMLResponse(ssoidpname, ssospname);
If not, then the error is likely caused by a bug in the SAML implementation.
By @BKBK
I agree, except that I believe the bug lies in the Sandbox implementation preventing the SAML plugin from reading the XSD document needed for basic functionality.