我正在寻找一种解决方案,将安全性集成到我们的应用程序中,该应用程序提供SSO但HTTP基本也是如
我们系统的一个自动化部分只能支持基本身份验证,我们非常关注它.目前,我们的目标是将Kerberos用于我们的SSO解决方案,然后还支持基本(非常有限的使用).所有这些都将保护通过resteasy运行的RESTful Web服务.
有没有人在弹簧安全链接的Kerberos和BASIC解决方案中看到任何固有的不可能性？我们遇到了WildFly的问题,并且无法支持多种不同的身份验证方法,这些方法在他们的握手中使用HTTP响应代码.
感谢您的投入
我没有证据表明它会起作用,但我认为你应该能够用基本的auth链接你的kerberos auth而没有任何问题.我分享了我对此的看法……
思想1：FilterChains
支持多种身份验证方法的技巧是正确设置身份验证筛选器的顺序.
如果订单错误,客户端可能会挂起基本身份验证,并且可能永远不会到达kerberos身份验证过滤器,因为会弹出浏览器的基本身份验证对话框.这可能取决于如何在Spring中实现基本身份验证提供程序和过滤器.无论如何,如果订单是正确的,那么在kerberos过滤器(基本认证过滤器)之后的链接中的下一个过滤器将开始工作.
思想2：Kerberos auth不应该破坏基本身份验证
浏览器应该将与kerberos服务提供商的通信视为与基本auth提供商的通信不同,因为协议是不同的.
SAML通信在it’s own namespace运行,因此在我看来它不应该影响基于HTTP头中的授权元素的基本身份验证通信.
编辑：即使关于命名空间的假设在浏览器行为中没有任何作用,sequence diagram中的步骤6也将是关键点.当过滤器链接正确时,Spring应该返回401响应,如401 – 拒绝访问 – WWW-身份验证 – 基本域=“您的域”,这将强制您的浏览器进入基本身份验证.
思想3：Spnego在Spring Security Kerberos中进行谈判
Spring Security Kerberos文档中的Spnego configuration实际上是基于这些想法.这也可以在样本中看到,在this WebSecurityConfig.java的第49和50行
如果遇到麻烦我会感到惊讶.
最后一个想法
如果没有要求强制您进行基本身份验证,我建议不要使用它.更好地保持基于令牌的身份验证.即使我不完全同意这个博客的所有细节,它也会解释why basic auth shouldn’t be used,如果你能避免的话.
