当前位置: 首页 > 知识库问答 >
问题:

使用Okta的Spring Security性&自定义重定向==重定向太多

叶淇
2023-03-14

当使用自定义重定向URL配置Spring security时,该URL使用基本URI模板变量,如下所示:https://docs.Spring.io/Spring-security/site/docs/5.2.12.release/reference/html/oauth2.html#oauth2client-auth-code-redirect-uri

应用程序进入了太多重定向的循环。

此配置工作:spring.security.oauth2.client.registration.okta.redirect-uri={baseUrl}/login/oauth2/code/{registrationId}

由于证书和负载均衡器以及所有这些,我们需要欺骗spring重定向到https而不是它运行的http。所以我们需要修改的基础。

使用基URL,我们可以从浏览器中看到以下循环:

  • 用户访问应用程序URL:https://myapp
  • 使用与应用程序匹配的redicrect url重定向到Okta进行登录
  • 使用来自Okta的代码重定向回应用程序
  • 被重定向到MyApp中他们正在寻找的页面
    null

我的结论是:设置重定向URL是正确地调用Okta,但会影响应用程序如何响应重定向调用。

当调试打开时,下面是一个工作调用堆栈:

  • 2021-11-19 12:59:21.690 DEBUG 7400---[nio-8080-exec-4]o.s.security.web.filterchainproxy:Securing GET/login/oauth2/code/okta?code=es23ulhg3psixke3fsk8vaicitmiakozhj4ku72n5k4&state=0w_8uffbbnhb5vnt31w4j2pvd1he1f3qspoma5_h7c%3d
  • 2021-11-19 12:59:21.690 DEBUG 7400---[nio-8080-exec-4]S.S.W.C.SecurityContextPersistenceFilter:将SecurityContextTholder设置为空SecurityContext
  • 2021-11-19 12:59:22.855 DEBUG 7400---[nio-8080-exec-4].s.changeSessionidAuthenticationStrategy:从32a94cbeb8bb3474fc1fe355f283a3cd更改了会话id

当它不起作用的时候:

  • 2021-11-19 12:55:37.359 DEBUG 1240---[nio-8080-exec-5]o.s.security.web.filterchainproxy:Securing GET/login/oauth2/code/okta?code=khasdirxodjk24dmaljdyfzlawy-ilvap_qlmtb0j8k&state=le1ddql8zxmajkd6xwbli-c42k_-h6mfrlvhhi4gyhw%3d
  • 2021-11-19 12:55:37.359 DEBUG 1240---[nio-8080-exec-5]S.S.W.C.SecurityContextPersistenceFilter:将SecurityContextTholder设置为空SecurityContext
  • 2021-11-19 12:55:37.359 DEBUG 1240---[nio-8080-exec-5]O.S.S.W.A.AnonymousAuthenticationFilter:将SecurityContextTholder设置为anonymous SecurityContext

共有1个答案

麻鹏鹍
2023-03-14

这里面有几个问题。

首先,您不需要“愚弄”Spring来知道您的应用程序是https还是HTTP。我猜您在反向代理后面运行,只需确保设置了正确的X-forwarded-*标头:

https://docs.spring.io/spring-boot/docs/current/reference/html/howto.html#howto.security.enable-https

对于“太多重定向”问题,这通常是应用程序端的配置错误(我猜是无效的客户机ID、客户机机密或颁发者。

经常发生的情况是,您的应用程序重定向到IdP(Okta),IdP对用户进行身份验证,然后重定向回您的应用程序。

 类似资料:
  • 我已经配置了一个SAML2。Okta中的0 IdP(即Okta是SAML2.0 SP)。 通过SAML成功完成IdP启动的身份验证后,我希望用户被重定向到自定义应用程序。因此,我将Okta(SP)上的“中继状态”配置为h_ttps://mydomain/customApp/customPath. 但是,出于安全原因,我认为SP没有将用户重定向到绝对URL,而是将get重定向到h_ttps://my

  • 我有一个简单的php应用程序,它显示用户入职的表单。我使用SimpleSamlPhp作为SP,使用OKTA作为IDP。当我访问应用程序的url时,我会得到无限重定向。这些是我在OKTA中的设置: 我的应用程序的网址是:http://service.example.com/Analytics/ui/onboard.php。为回发网址,目标,收件人和受众限制设置了相同的网址 在SP端,我有以下代码:

  • 当使用Keycloak-js(版本:4.0.0)在Angular4中创建会话时,SSO不起作用 null 响应URL: http://localhost:3000/login/generic_oauth#state=wwxu1iywxtsevsxwcfzwhpz7opm63dbu5aombtmdjhe%3d&session_state=6ec8255b-ed4c-4399-951c-0241ce7

  • 我正在使用Thymeleaf开发一个简单的登录表单 我试图通过将以下属性放入我的应用程序来禁用默认的安全登录屏幕。属性: 并将以下配置添加到我的SecurityConfig中,以便除"/登录"和"/资源"之外的任何URL都将获得身份验证: 我的LoginController是明确的: 有人知道为什么会这样吗?

  • 我想知道301和307重定向之间的区别。 我希望通过自制url重定向器生成反向链接,我希望任何“链接果汁”或“页面排名果汁”都能直接从原始主页流向最终url,但如果其中一个原始主页出现问题,我希望能够通过删除该特定页面的重定向链接来关闭该链接。有道理? 我的理解是,301是永久性的,这意味着谷歌将看到301并更新其缓存的URL作为最终目的地,而不管我以后是否取消重定向。 如果我使用307,它将不会

  • 使用授权代码流拥有一个受Spring Security oAuth2保护的Spring boot mvc应用程序。当在本地机器上部署和运行时,应用程序将重定向到正确的重定向uri以进行登录。但是在我们的kubernetes部署中,应用程序前面有一个api网关,可以通过以下路径访问应用程序 https:/// 其中k8名称空间名称是kubernetes名称空间名称,app名称是应用程序在名称空间中的