Shibboleth SP игнорирует MetadataProvider - PullRequest
2 голосов
/ 03 октября 2019

Я пытаюсь запустить Shibboleth SP впервые, но я сразу же столкнулся с проблемой, которую я не понимаю в течение трех дней: /

Я использую образ докера unicon/shibboleth-sp в качестве базыначать с. Пока что я только что изменил shibboleth2.xml в двух местах. Я записал конкретный IdP entityID в раздел <SSO> и добавил <MetadataProvider>, который указывает на внешний XML-файл, содержащий метаданные IdP.

ИМХО этого должно быть достаточно для перенаправления наIdP, когда я пытаюсь получить доступ к защищенному URL на SP. Но вместо этого я получаю исключение Shibb No MetadataProvider available.

Это изменения, которые я внес в 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>

После отладки в течение нескольких дней я уверен, чтоSP правильно анализирует тег <MetadataProvider>, но, похоже, полностью его игнорирует. Если для параметра Log-Levels установлено значение DEBUG, это означает, что MetadataProvider анализируется (его структура XML отображается в выводе журнала), но он не пытается получить доступ к URL-адресу. Нет даже запроса DNS для www.aai.dfn.de и он не пытается получить доступ к URL. Также в журнале нет ошибок. Нет даже намека на то, что он пытается загрузить внешние метаданные в журналы. Первая и единственная ошибка, которую я получаю в лог-файлах, это No MetadataProvider available после попытки доступа к защищенному ресурсу.

Я никогда раньше не устанавливал Shibboleth SP (потому что все говорили мне, что это PITA). Я не уверен, что это проблема Shibboleth SP или образа докера. Скорее всего, я проблема, и я просто упускаю что-то довольно очевидное ...

Мне нужна помощь:)

Полный код, который я использовал, можно найти здесь: https://gitlab.com/xsrf/shibb-sp/tree/5380f4550ac1a5ffb47d96138d837f1cf6acdb60

1 Ответ

1 голос
/ 03 октября 2019

Когда я вижу это, обычно это проблема с разрешениями ... т.е. пользователь, который запускает процесс shibd, не имеет доступа ни к файлу метаданных (или, более вероятно, в этом случае, файл разрешений, используемый для проверки),Я думаю, что просто сделать docker add в Dockerfile недостаточно для этого места назначения, потому что shibd не может прочитать /etc/ssl/aai/.

Я должен был бы взять ваш репозиторий и попробовать сам, чтобы понять, что делать именно, но кажется, что бы быстро выдумать, чтобы вместо этого поставить сертификат в /etc/shibboleth. shibd может прочитать этот каталог.

РЕДАКТИРОВАТЬ: похоже, что он не может загрузить эти метаданные, в дополнение к проблеме с разрешениями ... Я исправил проблему с разрешениями, добавив

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

в ваш Dockerfile.

Теперь я вижу эту ошибку, когда пытаюсь проверить конфигурацию:

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

И, конечно же ... пытаюсь отбросить этот URL из контейнера докератерпит неудачу:

[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>

Даже если это происходит с моей локальной машины. Использование статического файла работает, см .: https://i.imgur.com/gXxC7z9.png, что, в основном, я и ожидал увидеть для SP, который фактически не интегрирован с этим IdP.

Итак, проблемаЯ думаю, что он лежит где-то в вашей докерной сети.

РЕДАКТИРОВАТЬ # 2: Нет, просто убил ваш фиктивный веб-сервер, который я как-то не подключал, работал, и он работал просто отлично. Это как раз то, что я сказал. Добавьте эти две RUN строки в конец вашего Dockerfile, и он должен работать.

...