SSO在不同的雄猫中有2个弹簧应用

时间:2014-08-13 08:32:06

标签: java spring tomcat spring-security single-sign-on

我被要求将我们的webapp集成到第三方Web应用程序

  • 两者都具有相同的Spring安全配置
  • 入口点将始终是第三方webapp
  • 集成将通过IFrame,除非有更好的SSO方式

因此,如果您在同一个Tomcat实例中同时拥有两个webapps,您可以启用SSO小部件,并且您可以跨Web应用程序获取SSO,但由于多种原因,我们在自己的Tomcat服务器中运行Web应用程序。

之前我曾使用过Jasig CAS来管理SSO服务,但由于主要的webapp不是由我们设计或维护的,而且只有一个入口点,我正在寻找一种管理身份验证的微创方式。

Cookie是否足以让我看到其他东西?

1 个答案:

答案 0 :(得分:0)

在考虑之后,我可以看到3种主要可能性:

  • 在两个应用程序上将身份验证移动到CAS。优点:强大且经过验证的解决方案,CasAuthenticationProvider可以使用现有的AuthenticationUserDetailsService加载角色,允许基于此cas服务器对任何应用程序进行首次身份验证(即使不是当前要求) - 缺点:也许只有2个应用程序的重型配置
  • 使用第一个应用程序的会话cookie作为参考。如果您可以设法在第二个应用程序上获取它,则使用自定义预验证过滤器来获取cookie并从第一个应用程序询问userId。优点:如果有一个页面可以在第一个应用程序中获取userId(用户名或...),则无需更改 - 缺点:您可能需要在2个应用程序之前放置一个通用的反向代理他们似乎来自同一个服务器,以便能够在第二个应用程序中获取cookie,看起来像中间人攻击的人,可能需要第二个应用程序的自定义会话cookie
  • 在第一个应用上添加自定义过滤器,该过滤器设置包含令牌的自定义Cookie,并可由第二个应用检索。过滤器还应拦截URL并在提交令牌时发回userId。然后在第二个应用程序上添加一个自定义的预验证过滤器,它只获取此令牌并要求userId进行第一次过滤。优点:在第一个应用程序中添加一个简单的过滤器,与应用程序的其余部分几乎没有交互,看起来相当简单和健壮 - 缺点:需要在两个应用程序上进行自定义过滤器以及由于广泛的测试

我建议你考虑第一或第三种解决方案,即使它们需要对第三方应用程序的弹簧安全性稍作修改,因为第二种听起来确实是一种肮脏的黑客攻击