在Windows和Linux上使用Kerberos的SSO

Question

我们有一个内部开发的基于客户机/服务器的应用程序。客户端和服务器通过TCP/IP连接与特定于应用程序的协议进行通信。客户端在Windows上运行，服务器在Linux上运行。所有计算机都位于相同的Active Directory/Kerberos域/领域中。

目前，用户在启动应用程序时输入用户名和密码。服务器检查用户名和密码（身份验证）。服务器还根据用户名确定对资源的访问（授权）。

我们希望向应用程序添加单点登录（SSO）功能。也就是说，我们不希望用户输入用户名和密码，但希望以当前Windows用户身份自动登录。

当然，必须安全地确定当前Windows用户。

我想出了以下设置：

1. 我在Windows上使用SSPI（协商），在Linux上使用GSSAPI
2. 当客户端连接到服务器时，它使用AcquireCredentialsHandle（协商）获取当前Windows用户的凭据
3. 客户端使用InitializeSecurityContext（协商）根据这些凭据生成令牌
4. 客户端将令牌发送到服务器
5. 服务器使用gss\u acquire\u cred（）获取服务的凭据。这些存储在中。keytab文件
6. 服务器从客户端接收令牌
7. 服务器使用gss\u accept\u sec\u context（）处理令牌。此调用还返回“源名称”，即客户端的当前Windows用户
8. 服务器使用“源名称”作为用户名：服务器不执行其他身份验证。服务器仍然执行授权

这是可行的，但我确实有一些问题：

1. 这安全吗？客户端不能指定客户端进程的Windows用户以外的任何其他用户名。如果一个用户拥有作为另一个用户（合法或非法）创建进程的凭据，则不允许这样做
2. 我是否应该执行其他检查以验证用户名
3. 在此设置中是否有其他实现SSO的方法？他们的优缺点是什么

Answer 1

您在这里描述的是验证用户的正确方法。您不必担心用户指定不同的名称；这就是Kerberos为您处理的事情。

如果客户端能够获得服务票证，那么他们必须能够针对KDC（Active Directory）进行身份验证。KDC创建包含用户名的服务票证，并使用服务的密钥对其进行加密。

客户端将无法使用假名为服务器创建票证，因为它没有加密票证所需的密钥。

当然，这一切都假设您已正确设置了所有内容；例如，客户端不应访问服务的keytab文件，并且服务的key tab中不应有任何主体，除了它自己的主体。

这里有一个非常详细的解释它是如何工作的。