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

时间:2018-11-02 19:17:06

标签: saml okta shibboleth sp idp

我现在正在旋转一个大轮子。请说明一下。 反向代理正在使用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=~~~&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"/>

此发行者网址正确吗?为什么会循环以及如何解决?

1 个答案:

答案 0 :(得分:1)

问题Q#1:仅当您要使用Tomcat管理器来保护应用程序时,才需要Tomcat用户。否则,不会。

问题Q2:您在SAML中列出了<SSO entityID="http://www.okta.com/~~~~">Destination="https://okta sso/sso/saml"。您可能要检查http / https。这是循环的非常常见的原因。消除任何潜在的http / https不一致。

FWIW颁发机构对我来说似乎正确...这就是您在entityID="https://hostname/shibboleth-sp"中指定的

相关问题