Relative paths in Shibboleth XML catalogs are resolved against /usr/share/xml/opensaml
Basics
Technical
Logistics
Basics
Technical
Logistics
Description
I'm trying to write some automated test cases using cxxtest for some extra handlers that I wrote for Shibboleth. This is working out well so far, but I'm now at the point where I would like to spin up a complete Shibboleth instance, much in the same way as shibd does.
My folder structure looks something like this:
The idea being that each folder test1, test2 etc. serves as the "installation root" for the Shibboleth instance for that test.
The problem I'm running into is that I can't get Shibboleth to use relative paths in its XML catalog. I need to use relative paths in the Shibboleth catalog because these test cases will be checked in to source control and could end up anywhere on disk.
I know from reading the source code that a relative path to a catalog file, as well as relative paths inside the catalog files, are resolved using XMLTooling's PathResolver.
So what I'm trying to do is to:
Set the installation prefix to /absolute/path/to/shibsptest/resources/test1 (I can get this absolute path dynamically in the code)
Set SHIBSP_XMLDIR to share/xml
Specify the location of the Shibboleth catalog file as just catalog.xml in SHIBSP_SCHEMAS, while still using absolute paths to the OpenSAML and XMLTooling catalogs, and
Therefore hopefully be able to use relative paths in share/xml/shibboleth/catalog.xml, like this:
shibboleth/catalog.xml
To be clear, the issue is only with loading the Shibboleth catalog file; I can get absolute paths to the catalogs for OpenSAML and XMLTooling from the build system, and the paths inside both of those are also all absolute paths (I know from stepping through the code with a debugger that these catalogs load fine).
I.e., my SHIBSP_SCHEMAS looks like this:
On startup though, it resolves the relative catalog.xml path to /usr/share/xml/opensaml/catalog.xml. Additionally, if I temporarily hardcode the absolute path to the Shibboleth catalog.xml and try again, it's doing the same thing for all of the relative paths inside the catalog file.
Stepping through the code, the reason seems to be that the catalog loading is done before XMLTooling's PathResolver is configured with the Shibboleth default prefix and package name, but after initialization of the OpenSAML library:
What ends up happening is that the SAMLConfig sets the package name in the PathResolver to "opensaml", and leaves everything else at the defaults from the PathResolver constructor. Because loadCatalogs() then reuses that same PathResolver instance, the result is that it's resolving relative paths to XML files to /usr/share/xml/opensaml.
I would've expected it to resolve according to the settings configured for Shibboleth using SHIBSP_PREFIX, SHIBSP_XMLDIR etc. Maybe the fix is to load the catalogs only after the PathResolver is configured according to the Shibboleth settings?
I'm trying to write some automated test cases using cxxtest for some extra handlers that I wrote for Shibboleth. This is working out well so far, but I'm now at the point where I would like to spin up a complete Shibboleth instance, much in the same way as shibd does.
My folder structure looks something like this:
The idea being that each folder
test1,test2etc. serves as the "installation root" for the Shibboleth instance for that test.The problem I'm running into is that I can't get Shibboleth to use relative paths in its XML catalog. I need to use relative paths in the Shibboleth catalog because these test cases will be checked in to source control and could end up anywhere on disk.
I know from reading the source code that a relative path to a catalog file, as well as relative paths inside the catalog files, are resolved using XMLTooling's PathResolver.
So what I'm trying to do is to:
Set the installation prefix to
/absolute/path/to/shibsptest/resources/test1(I can get this absolute path dynamically in the code)Set
SHIBSP_XMLDIRtoshare/xmlSpecify the location of the Shibboleth catalog file as just
catalog.xmlinSHIBSP_SCHEMAS, while still using absolute paths to the OpenSAML and XMLTooling catalogs, andTherefore hopefully be able to use relative paths in
share/xml/shibboleth/catalog.xml, like this:shibboleth/catalog.xml
To be clear, the issue is only with loading the Shibboleth catalog file; I can get absolute paths to the catalogs for OpenSAML and XMLTooling from the build system, and the paths inside both of those are also all absolute paths (I know from stepping through the code with a debugger that these catalogs load fine).
I.e., my
SHIBSP_SCHEMASlooks like this:On startup though, it resolves the relative
catalog.xmlpath to/usr/share/xml/opensaml/catalog.xml. Additionally, if I temporarily hardcode the absolute path to the Shibbolethcatalog.xmland try again, it's doing the same thing for all of the relative paths inside the catalog file.Stepping through the code, the reason seems to be that the catalog loading is done before XMLTooling's PathResolver is configured with the Shibboleth default prefix and package name, but after initialization of the OpenSAML library:
What ends up happening is that the SAMLConfig sets the package name in the PathResolver to "opensaml", and leaves everything else at the defaults from the PathResolver constructor. Because
loadCatalogs()then reuses that same PathResolver instance, the result is that it's resolving relative paths to XML files to/usr/share/xml/opensaml.I would've expected it to resolve according to the settings configured for Shibboleth using
SHIBSP_PREFIX,SHIBSP_XMLDIRetc. Maybe the fix is to load the catalogs only after the PathResolver is configured according to the Shibboleth settings?