OKTA(IdP) - 带有 Tomcat 反向代理的 Shibboleth(SP)答案

【问题标题】：OKTA(IdP) - Shibboleth(SP) with reverse proxy to TomcatOKTA(IdP) - 带有 Tomcat 反向代理的 Shibboleth(SP)
【发布时间】：2018-11-02 19:17:05
【问题描述】：

我现在正在旋转一个大轮子。请解释一下。反向代理正在使用 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 文件下载和定位。 cert 也会生成并放置在同一文件夹中。

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=~~~&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"/>

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

【问题讨论】：

标签： saml okta shibboleth sp idp

【解决方案1】：

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

关于 Q#2：您从 SAML 中列出了 <SSO entityID="http://www.okta.com/~~~~"> 但 Destination="https://okta sso/sso/saml"。您可能需要检查 http/https。这是循环的一个非常常见的原因。消除任何潜在的 http/https 不一致。

FWIW Issuer 在我看来是正确的...这就是您在 entityID="https://hostname/shibboleth-sp" 中指定的内容

【讨论】：

感谢您回答我的问题。我更改了标签。 xxx.oktapreview.com/app/xxx/xxxx/sso/saml"discoveryProtocol="SAMLDS"discoveryURL="ds.example.org/DS/WAYF">SAML2 。现在我没有循环，但它给了我 Shibboleth 错误消息，例如“未知或无法使用的身份提供者/提供您的登录凭据的身份提供者未被授权使用此服务或不支持必要的功能/身份提供者查找失败~~
我需要在这里更改 discoveryProtocol / discoveryURL 吗？
如果您没有使用发现服务，即您只使用一个 IdP...那么不，您只需删除 discoveryURL 和 discoveryProtocol。
SSO 标记中列出的 entityID 必须明确是 IdP 元数据列出的内容...查看 Okta 元数据 xml 文件并确保您使用的正是第一行列为 entityID 的内容那个文件。
是的...您需要解析服务器变量。安装 Tomcat 后，我们通常会在 Tomcat 中设置 AJP 连接器，然后使用 shibboleth 将属性映射为 AJP_attributename，即 AJP_uid 或 AJP_email。然后你只需要在你的登录页面上选择那些。如果登录页面受 Shib 保护，用户将被重定向登录到 IdP，并被推送回该页面，并在环境变量中写入属性信息。因此，您知道他们是否已经进来并且服务器变量在那里，这是一个合法登录，您可以继续，知道您需要的任何属性。