Owe*_*wen 5 ajax shibboleth single-sign-on
我的大脑即将因缺乏对SSO/SAML的理解而爆发.我目前正在开发一个项目,我们正在使用shibboleth实现一个SSO身份提供者.
我们已启动并运行SSO,并且能够通过一个应用程序进行身份验证并导航到另一个应用程序.现在,下一个要求是让App A返回一个页面,该页面对App B进行Ajax调用而不进行挑战.
现在我们已经设置了工作前端通道(通过浏览器重定向),然后当我们对App A进行Ajax调用时,我们得到301响应,并且SP/IdP之间的重定向开始,Ajax显然不遵循.
另一方面,如果我们从App A到App A进行Ajax调用,那么它通过它的本地会话Id发送,并且不需要发送重定向来与IdP通信.
现在,如果我通过浏览器手动导航到App B并允许所有重定向发生(因此也检索App B的本地会话cookie).然后我仍然无法通过App A的响应发出Ajax请求.原因很明显,浏览器不会通过App A的cookie信息发送,因为我们正在App A的域上点击页面.
所以我的问题如下:
如果App A和App B是兄弟子域,我们能以某种方式让浏览器通过所有必需的会话cookie吗？
我认为这种Sp/IdP通信可以通过反向通道发生,作为通过浏览器发生的重定向.我不明白这是怎么可能的:-).如果我通过应用程序A登录,那么IdP会添加它自己的会话cookie,因此在访问应用程序B后重定向发生时不必重新验证我.但是,如果这不通过重定向完成,那么当我访问应用程序B时什么可以发送给IdP来验证我,因为我的浏览器首先没有将IdP的cookie传递给App B.
注意:
对不起,如果不太清楚,我现在真的无法解释这个问题.也许我最好解释一下我需要实现的目标.
有任何想法吗？干杯,克里斯.
小智 0
尽管这取决于您使用的系统，但让我给您一个想法。使用令牌（例如 JWT-Json Web 令牌）并将其用作辅助身份验证方法（将令牌链接到“用户”）。一旦“用户”通过 SSO 进行身份验证，即可在您的服务器上生成此令牌。然后将令牌传递给浏览器并在每个请求中使用它。
现在，重定向怎么样？据我了解，您正在使用两个 SP（服务提供商），每个“子域”一个。如果是这样，则可以使用令牌对从网站 A 到网站 B 的请求（尽管有 CORS 和其他配置）进行身份验证（您可以添加此身份验证方法，以便如果存在令牌，则不需要其他身份验证 - 该请求通过了安全性层）。
现在，尽管有这个想法，关于重定向和保持会话，IdP/SP 交互提供了一个“身份”，但是一旦您的服务器接收到它（在 SP 上），您就可以设置会话（例如可以通过cookie，...），验证权限、角色等。那么，问题不在于 IdP/SP 交互，而在于会话验证。这里使用令牌可能是一个好主意，因为您想避免通过 JS 进行 cookie 管理（不安全）。
我希望这可以帮助您理解这个过程，以便您可以通过降低整体的复杂性来找到其他想法。