![SSO 作为 Web 前端而不是外部链接服务](https://linux22.com/image/752672/SSO%20%E4%BD%9C%E4%B8%BA%20Web%20%E5%89%8D%E7%AB%AF%E8%80%8C%E4%B8%8D%E6%98%AF%E5%A4%96%E9%83%A8%E9%93%BE%E6%8E%A5%E6%9C%8D%E5%8A%A1.png)
在我们的一个团队中,我们一直在快速且独立地开发或部署大量专用 Web 服务。其中一些是我们自己构建的(使用 Django、Flask、Node 等),其他则是我们刚刚运行的开源项目(例如 Wekan、Nifi 等)。我们维护 SSO 以集中管理用户、开发人员和管理员的凭据和权限,并运行 KeyCloak(提供 OIDC 和 SAML)组合以管理应用程序用户,以及 Dex 以控制 Kubernetes 凭据(所有服务都部署在该集群内)。
然而,我们很快就遇到了让 SSO 真正发挥作用的困难。每个应用程序和 Web 框架都有不同的集成 SSO 的方式(如果它支持的话)。我们不得不放弃一些功能,因为它们无法与我们的 SSO 基础设施兼容。我们越来越不愿意部署新类型的服务,因为每次集成 SSO 的时间成本都很高。从长远来看,这可能比在每个服务上维护单独的凭据要省力,但至少在短期内不会省很多。
我的问题是:既然我们控制着我们的网络和集群,那么是否有一种好的或常见的方法来设置一个与 SSO 集成的单一 Web 门户,然后嵌入或代理各个服务,然后这些服务可能是不安全的(但只能从启用 SSO 的代理访问)或以某种方式传递用户身份?这是与定义明确的协议或常见的开源解决方案有关的常见事情吗?还是我找不到这样做的原因?似乎应该有一些与 SSL 终止等效的身份验证/身份。
答案1
您可以使用例如反向代理作为具有集中身份验证/授权的入口点。
但是,这仅提供了一种规范/控制访问的方法,并且不会提供所访问服务中的用户/组/权限信息。
许多服务还提供 LDAP 集成,这是目录数据最受支持/最常用的标准之一。LDAP 也可以用作 KeyCloak 的后端。
在许多情况下,服务的 LDAP 连接设置非常简单,在某些应用程序中,只有商业版本才支持细粒度访问。
LDAP 通常通过用于 DNS 和 Windows 登录的 Active Directory 基础架构提供。