проблема с SP shibboleth в контейнере докеров за прокси-сервером

Я пытаюсь настроить shibboleth, работающий в контейнере docker за прокси.

В настоящее время я использую я могу быть перенаправлен на страницу idp shibboleth, где я могу ввести свои данные для входа, и shibboleth аутентифицирует меня. Ошибка 404 при попытке перенаправить обратно на: https://my-service.org/Shibboleth.sso/SAML2/POST

Я не могу сказать, проблема ли это apache или что-то в этом роде с конфигурацией shibboleth.

Есть сервер с запущенным apache и docker. Apache здесь передает трафик в контейнеры докеров, работающие на том же сервере. У меня dns указывает доменное имя на прокси. Назовем его «my-service.org». Конфигурация прокси-сервера apache для my-service.org выглядит следующим образом:

<IfModule mod_ssl.c>
    <VirtualHost *:80>
        ServerName my-service.org
        ServerAdmin devs@blah.org
        DocumentRoot /var/www/html/my-service

        Redirect permanent / https://my-service.org/

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
    </VirtualHost>
    <VirtualHost _default_:443>
        ServerName my-service.org
        ServerAdmin devs@blah.org
        DocumentRoot /var/www/html/my-service

        ErrorLog ${APACHE_LOG_DIR}/docker-dev/my-service.log
        CustomLog ${APACHE_LOG_DIR}/docker-dev/my-service_ssl_access.log combined

        SSLEngine on
        SSLCertificateFile  /etc/ssl/certs/blah.crt
        SSLCertificateKeyFile  /etc/ssl/private/blah.key
        SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
        SSLProtocol All -SSLv2 -SSLv3
        SSLCompression off
        SSLHonorCipherOrder on

        ProxyPreserveHost On
        RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}
        RequestHeader set X-Forwarded-SSL expr=%{HTTPS}
        ProxyPass / http://127.0.0.1:8088/
        ProxyPassReverse / http://127.0.0.1:8088/       
    </VirtualHost>
</IfModule>

Контейнер 'my-service' основан на контейнере 'php: 7-apache-buster' и запускает apache с shibd. Это часть стека для создания докеров. Конфигурация контейнера apache следующая:

<VirtualHost *:80>
  ServerAdmin me@blah.org
  DocumentRoot /var/www/html/my-service

  <Directory /var/www/html/my-service/>
      Options Indexes FollowSymLinks MultiViews
      AllowOverride All
      Order deny,allow
      Allow from all
  </Directory>

  <Location "/shibboleth_login.php">
    AuthType shibboleth
    ShibRequestSetting requireSession 1
    ShibUseHeaders On
    require valid-user
  </Location>

  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Как я уже сказал, все работает до точки перенаправления обратно с shibboleth idp на SP, где он 404s. Журналы мало что говорят мне, но есть журнал ошибок, когда я загружаю конфигурацию apache контейнеров:

AH00558: apache2: Не удалось надежно определить полное доменное имя сервера, используя 172.17.0.6. Установите глобальную директиву ServerName для подавления этого сообщения

Я не уверен, повлияет ли это на ситуацию.

Одна вещь, которую я думал, может иметь влияние, это то, что у меня установлен shibboleth для обработки SSL :

<Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
                  checkAddress="false" handlerSSL="true" cookieProps="https">

Но моя конфигурация контейнера apache определяет только блок виртуального хоста HTTP. Как видите, прокси передает протокол контейнеру через заголовки X-Forwarded-Proto и X-Forwarded-SSL . Мне они нужны для php-приложения my-service, но я не уверен, влияют ли они на shibboleth. Первоначальное взаимодействие с idp работает нормально, не работает только обратное перенаправление.