OKTA(IdP) - Shibboleth(SP)，具有 Tomcat 的反向代理

Question

我现在正在旋转一个大轮子。请阐明一些情况。 反向代理正在与 Apache 配合使用。因此，当我访问 https://hostname/app/default.html 时，它会打开 Tomcat 应用程序 url。没问题。

tomcat 应用程序当前重定向到 https://hostname/app/login.html，其中有一个登录框。

1) 我需要在 Tomcat server.xml 上禁用 UserDatabase 吗？

<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) 配置此功能时，它会循环 OKTA SSO url。

在 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 响应。

然后，它会重定向到 OKTA SSO url。它永远不会结束。

https:// xxx.oktapreview.com/app/xx_reverse_proxy_/xxxx/sso/saml?SAMLRequest=~~~&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"/>

此发行人网址正确吗？为什么会循环以及如何修复？

Answer 1

Re Q#1：如果您要使用 Tomcat 用户保护应用程序（例如 Tomcat 管理器），则只需要 Tomcat 用户。否则不行。

回复问题#2：您列出了 SAML 中的

<SSO entityID="http://www.okta.com/~~~~">

但

Destination="https://okta sso/sso/saml"

。您可能想检查 http/https。这是循环的一个非常常见的原因。消除任何潜在的 http/https 不一致问题。

FWIW 发行人对我来说看起来是正确的...这就是您在

entityID="https://hostname/shibboleth-sp"

中指定的内容