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

本文介绍了OKTA(IdP)-具有反向代理到Tomcat的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=~~~&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:仅当您要使用Tomcat管理器来保护应用程序时，才需要Tomcat用户.否则，不会.

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

FWIW颁发者对我来说似乎正确...这就是您在entityID="https://hostname/shibboleth-sp"

中指定的内容

I am spinning a big wheel now. please shed some light.Reverse proxy is working with Apache. So, when I access https://hostname/app/default.html, it opens Tomcat app url. No issue.

The tomcat app currently redirects to https://hostname/app/login.html which has a login box.

1) Do I need to disable UserDatabase on 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) Is this Shibboleth configuration correct ?But, when I try configure this with OKTA- Shibboleth(3.0), it's looping OKTA SSO url.

In shibboleth2.xml

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

OKTA's metadata is downloaded and located with shibboleth2.xml file.cert is also generated and placed in the same folder.

3) Is this OKTA configuration correct ?In OKTA widget configuration menu,

- 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 : ??

right now, when I click on the widget on OKTA, it's looping.

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

contains SAML response.

then, it redirects to OKTA SSO url. It never ends.

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

This contains SAML request but it looks like this.

<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"/>

Is this Issuer url correct? Why is it looping and how to fix ?

解决方案

Re Q#1: You only need Tomcat users if you're going to protect an application with it, such as the Tomcat manager. Otherwise, no.

Re Q#2: You list <SSO entityID="http://www.okta.com/~~~~"> but Destination="https://okta sso/sso/saml" from the SAML. You might want to check http/https. This is a very common cause of looping. Eliminate any potential http/https inconsistency.

FWIW Issuer looks correct to me... that's what you specify in entityID="https://hostname/shibboleth-sp"

这篇关于OKTA(IdP)-具有反向代理到Tomcat的Shibboleth(SP)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！