Kerberos通过SASL：我需要获得票证吗？

Question

我正在为一个软件设计身份验证系统，并需要有关SASL和Kerberos服务如何交互的一些指导。

情况如下：

我有一个客户端/服务器应用程序本身很标准：只有注册用户才能使用执行操作。作为MVP，我通常会实现一个非常标准的解决方案：

• 数据库存储用户名+密码的盐渍哈希
• 来自HTTP上的客户端的身份验证尝试包括TLS上的用户名/密码
• 后端检查用户名/密码是否有效，并返回可在会话期间使用的承载令牌

然而，在这种情况下，存在复杂因素。我们系统的一些用户在内部使用Kerberos进行所有内部服务的用户身份验证。作为一项功能，我们希望将我们的软件与Kerberos集成，以便他们不必管理额外的用户组。

一位更高级的工程师建议我查看SASL，以便我们可以同时支持多个auth协议;例如，标准客户可以使用PLAIN方法（通过TLS）对其用户进行身份验证，而其他客户可以将身份验证仅限制为GSSAPI方法。

到目前为止，我清楚地知道如何设置事物来实现预期目标。但是，还有一个复杂因素。一些希望我们系统的auth支持Kerberos的客户拥有我们的系统将依赖的其他资源（如HDFS），这些资源也需要使用Kerberos进行身份验证。

我对Kerberos的理解是这样的：

• 客户端使用Kerberos的票证授予服务器进行身份验证
• 验证成功后，将返回TGT，可用于将来与系统中任何Kerberos服务的任何交互

现在到了这一点：我怎样才能使所有这些技术协调工作？我想要的是： - 客户端登录到我的服务器 - 我的服务器使用客户的Kerberos系统验证客户端 - 客户端正常 - 客户端从我的服务器请求 - 我的服务器需要访问客户的HDFS，这需要Kerberos auth - 服务器验证没有要求客户再次进行身份验证

我看到的一个可能的解决方案如下：

• 使我的服务器本身成为Kerberos用户
• 当服务器需要对HDFS执行操作时，请使用自己的凭据进行身份验证

然而，这有一个很大的缺点：假装客户的Kerberos系统有两个领域：一个可以访问HDFS而另一个没有。如果允许两个实际的用户使用我的系统，但只有一个可以使用HDFS，那么我将需要我自己的逻辑（以及数据库中的潜在对象）来确定谁可以执行需要访问HDFS的操作以及谁不能。

任何指针都会非常有用;如果不是很明显，我对这一切都很陌生。

提前致谢！

Answer 1

目前尚不清楚你的问题究竟是什么，但我会尽力解决我认为你问的问题。

首先，我只想澄清一下：

验证成功后，将返回TGT，可用于将来与系统中任何Kerberos服务的任何交互

这不太正确。 TGT使用户能够从KDC请求服务票据以获取特定服务。服务票证使用户能够访问特定服务。 TGT用于在请求服务票证时向KDC证明用户的身份。

客户端从我的服务器请求某些内容 - 我的服务器需要访问客户的HDFS，这需要Kerberos身份验证 - 服务器身份验证而不要求客户端再次进行身份验证

这是一个常见的问题，Kerberos解决方案称为委派。您应该尝试使用Kerberos委派，而不是提出自己的解决方案。也就是说，它的支持程度取决于您使用的技术堆栈。

Kerberos支持两种委托。第一种叫做“委托”，它通过将用户的TGT与服务票据一起发送到服务来工作。然后，该服务可以使用TGT代表用户从KDC获得新的服务票据。这种方法的缺点是，一旦服务获得用户的TGT，它就可以有效地模拟该用户访问用户能够访问的任何服务。您可能不希望该服务具有该自由度。

第二种委托称为约束委托（也称为services4user或S4U）。使用这种方法，客户端不会将其TGT发送到服务，但是允许服务向KDC请求服务票据以模仿用户。可以执行此操作的服务必须在KDC上列入白名单，以及可以请求票证的服务。这最终会产生更安全的方法，因为该服务无法模拟该用户只使用任何服务。

一位更高级的工程师建议我查看SASL，以便我们可以同时支持多个auth协议;例如，标准客户可以使用PLAIN方法（通过TLS）对用户进行身份验证，而其他客户可以将身份验证仅限于GSSAPI方法

是的，这是一个好主意。具体来说，我建议您为所有用户使用完全相同的会话身份验证机制。 Kerberos用户的唯一区别应该是他们获得会话的方式。您可以设置受Kerberos保护的登录URL，使其成为会话而不会挑战凭据。任何点击此URL并且没有Kerberos凭据的用户都可以被重定向到登录页面，这最终会使他们获得相同的会话对象（一旦他们登录）。

在后端，凭证检查逻辑可以使用SASL将Kerberos用户传递到KDC，将其他用户传递到本地身份验证机制。这为Kerberos不能为Kerberos用户工作的情况提供了无缝回退机制（由于时钟偏差等问题，这种情况很容易发生）

然而，这有一个很大的缺点：假装客户的Kerberos系统有两个领域：一个可以访问HDFS而另一个没有。如果允许两个实际的用户使用我的系统，但只有一个可以使用HDFS，那么我将需要我自己的逻辑（以及数据库中的潜在对象）来确定谁可以执行需要访问HDFS的操作以及谁不能。

这种情况正是您应该使用Kerberos委派而不是提出自己的自定义解决方案的原因。使用Kerberos委派，KDC管理员控制谁可以访问什么。如果您的服务尝试模拟用户使用HDFS，并且不允许他们访问它，则该身份验证步骤将失败并且一切都会正常。

如果您试图在自己的应用程序中隐藏KDC的授权规则，它们迟早会失去同步，并且会发生不好的事情。