проблема с shibboleth SP в docker контейнере за прокси - PullRequest
Новая
       47

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

0 голосов
/ 21 апреля 2020

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

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

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

На нем запущен сервер с apache и docker. apache здесь передает трафик c на контейнеры docker, работающие на том же сервере. У меня днс указать доменное имя на прокси. Давайте назовем это «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 с Шибд. Это часть docker -компонентного стека. Конфигурация 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 config:

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. Я нуждался в них для приложения «my-service» php, но не был уверен, влияют ли они на шибболет. Начальное взаимодействие с idp работает нормально, просто не работает перенаправление назад.

1 Ответ

0 голосов
/ 21 апреля 2020

Я понял, что мне нужно добавить атрибут ServerName следующим образом: 

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

  ServerName https://my-service.org:443
  UseCanonicalName On

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