OKTA(IdP) - Shibboleth(SP) 与 Tomcat 的反向代理
OKTA(IdP) - Shibboleth(SP) with reverse proxy to Tomcat
我现在在转一个大轮子。请说明一下。
反向代理与 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"/>
这个发行人url是否正确?为什么会循环以及如何修复?
Re Q#1:如果您要用它保护应用程序,例如 Tomcat 管理器,则只需要 Tomcat 个用户。否则,没有。
回复问题 #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"
中指定的内容
我现在在转一个大轮子。请说明一下。 反向代理与 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"/>
这个发行人url是否正确?为什么会循环以及如何修复?
Re Q#1:如果您要用它保护应用程序,例如 Tomcat 管理器,则只需要 Tomcat 个用户。否则,没有。
回复问题 #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"