single-sign-on - SPNEGO SSO 配置中的预身份验证用户有什么用？

Question

我正在使用 SPNEGO 来实现 SSO 解决方案。在配置过程中，我需要分两步使用域用户凭据:

1. 在 web.xml我的应用程序:

    <init-param>
         <param-name>spnego.preauth.username</param-name>
         <param-value>myuser</param-value>
    </init-param>
    <init-param>
         <param-name>spnego.preauth.password</param-name>
         <param-value>mypassword</param-value>
    </init-param>
   

2. 在 setspn命令:setspn -A <mySPN> myuser

当我使用此配置时，Java 应用程序使用 getRemoteUser() 检索用户“myuser”的用户名。所以 SSO 工作得很好。但是当我尝试以其他用户身份(在同一 Windows 服务器上)打开 session 时，它也起作用了，所以我有点困惑。这让我想到了这些问题:

为什么 SSO 对域中的所有其他用户都有效？我必须在 web.xml 和 setspn 命令中使用相同的用户吗？以及选择哪个用户？ SPN在Kerberos场景中的具体用途是什么？我是否必须在每台 Windows 计算机上执行命令 setspn 还是有办法只执行一次？

Answer 1

此帐户是 Kerberos 中定义服务器身份的一部分。

Kerberos 是一种对称 key 协议(protocol)。每个用户都有一个在用户和 KDC 之间共享的对称 key ，同样，每个服务(接受者)也有一个在服务和 KDC 之间共享的对称 key 。

当用户请求特定“服务主体”的票证时，KDC 将使用该服务的 key 加密返回它们。因此，为了让服务解密这些 Kerberos 票证，它还需要某种方式来了解与其自己的服务主体关联的 key 。

服务 key 通常是随机生成的，并通过“keytab”文件提供。但是，在 Active Directory 系统中，大多数服务帐户都是具有密码的常规用户帐户 - 因此它们的 key 可以从服务的密码派生。

看来你的SPNEGO模块supports both methods (参见第 150-160 行) – 可以为其提供 key 表或密码。

无论如何，该设置与将连接到您的服务的客户端完全无关。它仅建立服务器自己的身份。

What's the exact use of the SPN in the Kerberos scenario?

类似于HTTPS证书中的域名字段。例如，当浏览器对 https://example.com 执行 Kerberos 身份验证时，它将始终从 KDC 请求 SPN HTTP/example.com 的 Kerberos 票证.

如果您熟悉 OAuth2、SAML 或 JWT，我相信 Kerberos SPN 大致相当于 SAML 断言中的“audience”字段或 JWT 中的“aud”字段。

(请注意，浏览器仅通过其 SPN 来了解您的服务，并不关心在幕后使用的实际服务帐户 - 例如，Active Directory 恰好将 SPN 映射到真实的“在这种情况下，“user”帐户，但其他 Kerberos 实现的做法有所不同)

Do I have to use the same user in both web.xml and setspn command?

是的，它需要是同一个用户，因为服务必须能够解密为其 SPN 颁发的票证，因此它需要知道相同的对称 key 。

And which user to choose?

专为该服务创建一个新的专用帐户。 请勿使用真实的“个人”帐户。

使用长且高度随机的密码，并将其标记为不过期。此外，请确保在帐户选项中启用“帐户支持 Kerberos AES xxx 位”功能(假设您的 Java SPNEGO 事物支持 AES，它确实应该)。

Do I have to execute the command setspn in every windows computer or there is a way to do it just once?

不，在哪里执行它并不重要，因为它只编辑域 Controller 上的实际帐户 - 它不会在本地计算机上留下任何痕迹。 (具体来说，它为所提供的帐户设置 servicePrincipalName LDAP 属性。)

客户端仅通过 SPN 识别您的服务，他们无需了解 KDC 在幕后完成的帐户映射。