OKTA (IdP) - Shibboleth (SP) с обратным прокси для Tomcat - PullRequest
Новая
       159

OKTA (IdP) - Shibboleth (SP) с обратным прокси для Tomcat

0 голосов
/ 02 ноября 2018

Я сейчас вращаю большое колесо. пожалуйста, пролите немного света. Обратный прокси работает с Apache. Итак, когда я получаю доступ к https://hostname/app/default.html,, он открывает URL-адрес приложения Tomcat. Нет проблем.

Приложение tomcat в настоящее время перенаправляет на https://hostname/app/login.html, который имеет поле для входа.

1) Нужно ли отключать базу данных пользователей на Tomcat server.xml? 

<Resource name="UserDatabase" auth="Container"
          type="org.apache.catalina.UserDatabase"
          description="User database that can be updated and saved"
          factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
          pathname="conf/tomcat-users.xml" />

2) Это правильная конфигурация Shibboleth? Но когда я пытаюсь настроить это с помощью OKTA-Shibboleth (3.0), он зацикливает URL-адрес единого входа OKTA.

In shibboleth2.xml 

<ApplicationDefaults id="default" 
                         entityID="https://hostname/shibboleth-sp" 
                         REMOTE_USER="userid" >
   <SSO entityID="http://www.okta.com/~~~~">

Метаданные OKTA загружаются и располагаются вместе с файлом shibboleth2.xml. Сертификат также создается и помещается в ту же папку.

3) Это правильная конфигурация OKTA? В меню конфигурации виджета OKTA, 

- Single sign on url :https://hostname/Shibboleth.sso/SAML2/POST
- recipient url : https://hostname/Shibboleth.sso/SAML2/POST
- destination url :https://hostname/Shibboleth.sso/SAML2/POST
- audience restriction :https://hostname/shibboleth-sp  <-- above SP entityID
- default relay state : ??

прямо сейчас, когда я нажимаю на виджет в OKTA, он зацикливается. 

https://hostname/Shibboleth.sso/SAML2/POST

содержит ответ SAML.

затем перенаправляется на URL-адрес единого входа OKTA. Это никогда не заканчивается. 

https:// xxx.oktapreview.com/app/xx_reverse_proxy_/xxxx/sso/saml?SAMLRequest=~~~&amp;RelayState=~~~

Содержит запрос SAML, но выглядит так. 

<samlp:AuthnRequest 
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
AssertionConsumerServiceURL="https://hostname/Shibboleth.sso/SAML2/POST" 
Destination="https://okta sso/sso/saml" 
ID="xx" 
IssueInstant="2018-11-02T15:39:24Z" 
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
Version="2.0">
<saml:Issuer 
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://hostname/shibboleth-sp
</saml:Issuer>
<samlp:NameIDPolicy 
    AllowCreate="1"/>

Правильно ли указан этот URL-адрес эмитента? Почему это зацикливается и как это исправить?

1 Ответ

0 голосов
/ 04 ноября 2018

Re Q # 1: вам нужны только пользователи Tomcat, если вы собираетесь защищать с помощью приложения, такого как менеджер Tomcat. В противном случае, нет.

Re Q # 2: Вы перечисляете <SSO entityID="http://www.okta.com/~~~~">, но Destination="https://okta sso/sso/saml" из SAML. Возможно, вы захотите проверить http / https. Это очень распространенная причина зацикливания. Устраните любые потенциальные несоответствия http / https.

FWIW Issuer выглядит правильно для меня ... это то, что вы указываете в entityID="https://hostname/shibboleth-sp"

...