Single sign on 在Windows和Linux上使用Kerberos的SSO

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

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

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

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

我提出了以下设置：

我在Windows上使用SSPI（协商），在Linux上使用GSSAPI

当客户端连接到服务器时，它使用

AcquireCredentialsHandle（协商）

获取当前Windows用户的凭据

客户端使用

InitializeSecurityContext（协商）

根据这些凭据生成令牌

客户端将令牌发送到服务器

服务器使用

gss\u acquire\u cred（）

获取服务的凭据。它们存储在.keytab文件中

服务器从客户端接收令牌

服务器使用

gss\u accept\u sec\u context（）

处理令牌。此调用还返回“源名称”，即客户端的当前Windows用户

服务器使用“源名称”作为用户名：服务器不执行其他身份验证。服务器仍然执行授权

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

这安全吗？客户端不能指定除客户端进程的Windows用户之外的任何其他用户名。如果一个用户拥有作为另一个用户（合法或非法）创建进程的凭据，则不允许这样做

我是否应该执行其他检查以验证用户名

在此设置中是否有其他实现SSO的方法？他们的优点和缺点是什么

---

您在这里描述的是验证用户身份的正确方法。您不必担心用户指定不同的名称；这就是Kerberos为您提供的服务

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

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

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

---

对它的工作原理有一个非常详细的解释

“客户端不能指定当前Windows用户以外的任何其他用户名”>祝您好运。首先，“当前用户”是不明确的——当前进程的所有者？因为Windows操作系统可能有多个正在运行的会话（每个会话都有合法的Krb凭据）——多个RDP会话、在后台为服务帐户运行的计划任务……Kerberos是为在不安全的网络上进行安全身份验证而设计的。它不能防止客户端计算机上的凭据被盗（例如，密钥表文件泄漏）。为了防止creds被盗，您需要不同的工具——例如，要求客户端身份验证在交互模式下使用智能卡或类似的硬件设备来获取Kerberos票证。@SamsonScharfrichter我是指当前进程的所有者。如果有人设法入侵操作系统并访问他或她不应该访问的东西，那么这是一个问题，但不是我需要在应用程序中解决的问题。我的应用程序对于任何用户都可以做的事情都应该是健壮的，例如更改环境变量或使用被黑客攻击的客户端应用程序发送定制的消息。似乎我已经实现了答案中所述的解决方案，尽管这仅适用于Windows。这是个老问题，所以现在可能有更好的选择。