SPA webapp SSO 联盟
我有一个使用OpenIDConnect的Spa Web应用程序，可以使用本地KeyCloak进行身份验证和授权。 该应用程序现在使用AD，Kerberos门票和Central SSO转移到Windows Onprem基础架构。 用户在其Windows会话中登录，然后我们将能够在我们的水疗Web应用程序中透明地登录。 （即没有输入凭据） 如何将Kerberos票/身份验证转换为OpenIDConnect世界？魔术在哪里？ 我们可以在应用程序中添加一些kerberos吗？ 我们如何检索包含用户角色的访问令牌？
谢谢
I have an SPA web app using openidconnect for authentication and authorization with local keycloak.
This app is now moving to an windows onprem infrastructure using AD, kerberos tickets and a central SSO.
users log in in their windows session, and then we shall be able to transparently login in our SPA web app. (ie with out entering credentials)
How can I convert kerberos ticket/authentication into Openidconnect world? Where is the magic?
Shall we add some kerberos in our app?
how can we retrieve our access token containing the user role?
thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您的 SPA 应继续使用 OIDC 与 Keycloak 通信，并且 SPA 中的任何代码都不需要更改。您的 API 还将继续接收相同的访问令牌。
您只需要配置 Keycloak 以使用 AD 作为 LDAP 数据源进行身份验证。这是文章如何做到这一点。这是一项基础设施工作，而不仅仅是编码工作，因此我建议与 AD 管理员在环境设置方面进行协作。
AD 只是一种可能的身份验证方法，通过这种方式，您可以保持选择余地。您可能需要执行帐户链接，例如在迁移之前和之后识别相同的用户。这里可能涉及一些数据设置，例如确保AD具有与现有系统相同的电子邮件。
Your SPA should continue to talk to Keycloak using OIDC, and no code in the SPA should need to change. Your APIs will also continue to receive the same access tokens.
You should only need to configure Keycloak to use AD for authentication as an LDAP data source. Here is an article on how to do that. It is an infrastructure job rather than just a coding one, so I would recommend collaboration with AD administrators on the environment setup.
AD is only one possible authentication method, and by doing things this way you keep your options open. You are likely to need to perform account linking, eg to identify users the same before and after the migration. There may be some data setup involved here, eg ensure AD has the same emails as the existing system.