Shibboleth SP ignores MetadataProvider

I try to run a Shibboleth SP for the first time, but I immediately ran into an issue that I don't understand for three days now :/

I use the docker image unicon/shibboleth-sp as base to begin with. So far I've just modified shibboleth2.xml in two places. I wrote a specific IdP entityID into the <SSO> section and added a <MetadataProvider> that points to an external XML file containing the metadata of the IdP.

IMHO this should be enough to get redirected to the IdP when I try to access a protected URL on the SP. But instead, I get a Shibb-Exception No MetadataProvider available.

These are the changes I made to shibboleth2.xml:

<ApplicationDefaults entityID="https://sp.example.org/shibboleth" ... >
    ...
    <Sessions ... >
        ...
        <!--
        Configures SSO for a default IdP. To properly allow for >1 IdP, remove
        entityID property and adjust discoveryURL to point to discovery service.
        You can also override entityID on /Login query string, or in RequestMap/htaccess.
        -->
        <SSO entityID="https://testidp.aai.dfn.de/idp/shibboleth"
            discoveryProtocol="SAMLDS" discoveryURL="http://www.aai.dfn.de/DS/WAYF">
            SAML2
        </SSO>
        ...
    </Sessions>
    ...
    <MetadataProvider type="XML" id="dfn-aai-test-metadata"
        url="http://www.aai.dfn.de/fileadmin/metadata/dfn-aai-test-metadata.xml"
        backingFilePath="federation-dockermeta-metadata.xml" maxRefreshDelay="3600">
        <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
        <MetadataFilter type="Signature" certificate="/etc/ssl/aai/dfn-aai.g2.pem" verifyBackup="false"/>
    </MetadataProvider>
    ...
</ApplicationDefaults>

After debugging for days now I'm pretty sure that the SP correctly parses the <MetadataProvider> tag, but seems to completely ignore it. Setting Log-Levels to DEBUG show that the MetadataProvider gets parsed (its XML structure is visible in the log output), but it doesn't try to access the URL. There is not even a DNS request for www.aai.dfn.de nor does it try to access the URL. Also, there are no Errors in the log. There is not even a hint of it trying to load external Metadata in the logs. The first and only error I get in the logfiles is No MetadataProvider available after trying to access a protected resource.

I've never set up a Shibboleth SP before (because everybody told me it is a PITA). I'm not sure if it's a problem with the Shibboleth SP or the docker image. Most probably I'm the problem and I'm just missing something pretty obvious...

I need help :)

The complete code I used can be found here: https://gitlab.com/xsrf/shibb-sp/tree/5380f4550ac1a5ffb47d96138d837f1cf6acdb60

Solution

When I see this it's usually a permissions issue... i.e. the user that's running the shibd process doesn't have access to either the metadata file (or more likely in this case, the permissions file used to validate). I think just doing docker add in the Dockerfile isn't sufficient with that destination because shibd cannot read /etc/ssl/aai/.

I'd have to pull your repo and try it myself to work out what to do exactly, but it seems like a quick fudge would be to put the cert in /etc/shibboleth instead. shibd can read that dir.

EDIT: It looks like it can't download that metadata, in addition to the permission issue... I corrected the permissions problem by adding

RUN chown -R shibd:shibd /etc/shibboleth/
RUN chown -R shibd:shibd /var/cache/shibboleth/

to your Dockerfile.

Now I see this error when I try to test the config:

root@ac4861a1faae shibboleth]# /usr/sbin/shibd -t
2019-10-03 16:51:39 CRIT XMLTooling.Config : libcurl lacks OpenSSL-specific options, this will greatly limit functionality
2019-10-03 16:51:39 WARN Shibboleth.Application : insecure cookieProps setting, set to "https" for SSL/TLS-only usage
2019-10-03 16:51:39 WARN Shibboleth.Application : handlerSSL should be enabled for SSL/TLS-enabled web sites
2019-10-03 16:51:39 ERROR XMLTooling.libcurl.InputStream [dfn-aai-test-metadata]: error while fetching http://www.aai.dfn.de/fileadmin/metadata/dfn-aai-test-metadata.xml: (22) The requested URL returned error: 404 Not Found
2019-10-03 16:51:39 ERROR XMLTooling.ParserPool [dfn-aai-test-metadata]: fatal error on line 0, column 0, message: internal error in NetAccessor
2019-10-03 16:51:39 ERROR OpenSAML.MetadataProvider.XML [dfn-aai-test-metadata]: error while loading resource (http://www.aai.dfn.de/fileadmin/metadata/dfn-aai-test-metadata.xml): XML error(s) during parsing, check log for specifics
2019-10-03 16:51:39 WARN OpenSAML.MetadataProvider.XML [dfn-aai-test-metadata]: adjusted reload interval to 600 seconds
2019-10-03 16:51:39 WARN OpenSAML.MetadataProvider.XML [dfn-aai-test-metadata]: trying backup file, exception loading remote resource: XML error(s) during parsing, check log for specifics
2019-10-03 16:51:39 ERROR XMLTooling.ParserPool [dfn-aai-test-metadata]: fatal error on line 0, column 0, message: unable to open primary document entity '/var/cache/shibboleth/federation-dockermeta-metadata.xml'
2019-10-03 16:51:39 ERROR OpenSAML.MetadataProvider.XML [dfn-aai-test-metadata]: error while loading resource (/var/cache/shibboleth/federation-dockermeta-metadata.xml): XML error(s) during parsing, check log for specifics
2019-10-03 16:51:39 CRIT Shibboleth.Application : error initializing MetadataProvider: XML error(s) during parsing, check log for specifics
overall configuration is loadable, check console or log for non-fatal problems

And, sure enough... trying to CURL that URL from the docker container fails:

[root@ac4861a1faae shibboleth]# curl http://www.aai.dfn.de/fileadmin/metadata/dfn-aai-test-metadata.xml
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
</body></html>

Even though it succeeds from my local machine. Using the static file works, see: https://i.imgur.com/gXxC7z9.png which is basically what I'd expect to see for an SP that isn't actually integrated with that IdP.

~~So, the problem lies somewhere in your docker networking I think.~~

EDIT #2: Nope, just killed your dummy webserver that I somehow didn't connect was running and it worked just fine. It's a permissions thing like I said. Add those two RUN lines to the end of your Dockerfile and it should work.