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

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

В настоящее время я могу быть перенаправлен на страницу 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>

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

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.6. Set the 'ServerName' directive globally to suppress this message

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

Одна вещь, на которую я подумал, может повлиять, - это то, что у меня установлен 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 работает нормально, не работает только обратное перенаправление.