SPNEGO：成功协商和验证后的后续调用

Question

在过去的几天里，我使用 GSS-API 和 SPNEGO 构建了一个概念验证演示。目的是让用户通过 Http RESTful Web 服务单点登录访问我们的自定义应用服务器提供的服务。

持有有效 Kerberos Ticket Granting Ticket (TGT) 的用户可以调用启用了 SPNEGO 的 Web 服务，客户端和服务器将协商， 用户将被验证（通过 Kerberos 和应用程序级别），并且（在成功验证后）在他的票证缓存中拥有我的服务主体的服务票证。

使用带有 --negotiate 标志的 CURL 作为测试客户端时效果很好。

在第一次通过时，CURL 发出一个没有特殊标头的普通 HTTP 请求。该请求被服务器拒绝， 它将“WWW-Authenticate: Negotiate”添加到响应标头中，建议进行协商。 然后，CURL 从 KDC 获取服务票证，并发出第二个请求，这次使用 Negotiate + 请求标头中的包装服务票证 (NegTokenInit) 然后，服务器打开票证，对用户进行身份验证，并（如果身份验证成功）执行请求的服务（例如登录）。

问题是，从客户端到服务器的后续服务调用应该发生什么？ 客户端现在有一个有效的 Kerberos 服务票证，但通过 CURL 的附加调用使用 SPNEGO 进行与上述相同的两次传递。

在我看来，我有很多选择：

1) 每个服务调用都重复完整的 2 遍 SPNEGO 协商（就像 CURL 一样）。 虽然这可能是最简单的选择，但至少在理论上会有一些开销：客户端和服务器都在创建和拆除 GSS 上下文，并且请求通过网络发送两次，对于 GET 来说可能没问题，对于 POST 来说则更少，如以下问题中所述：

Why does the Authorization line change for every firefox request?

Why Firefox keeps negotiating kerberos service tickets?

但开销^* 在现实生活中是否明显？我想只有性能测试才能说明问题。

2) 第一次调用使用 SPNEGO 协商。一旦成功通过身份验证，后续调用将使用应用程序级别的身份验证。 这似乎是 Websphere Application Server 采用的方法，它使用轻量级第三方身份验证 (LTPA) 安全令牌进行后续调用。

https://www.ibm.com/support/knowledgecenter/SS7JFU_8.5.5/com.ibm.websphere.express.doc/ae/csec_SPNEGO_explain.html

最初这似乎有点奇怪。已经成功协商可以使用 Kerberos，为什么要退回到其他东西呢？另一方面，如果 GSS-API / SPNEGO 可以被证明会导致明显的开销/性能损失，那么这种方法可能是有效的。

3) 第一次调用使用 SPNEGO 协商。一旦成功通过身份验证和信任，后续调用将使用 GSS-API Kerberos。 在这种情况下，我不妨执行下面的选项 4)。

4) 转储 SPNEGO，使用“纯”GSS-API Kerberos。 我可以通过自定义 Http 标头或 cookie 交换 Kerberos 票证。

有最佳做法吗？

作为背景：客户端和服务器应用程序都在我的控制之下，两者都是用 java 实现的，而且我都知道“说”Kerberos。 我选择 SPNEGO 作为概念验证的“起点”，以及进入 Kerberos 和单点登录的世界，但这不是硬性要求。

概念验证在具有 FreeIPA 的 OEL Linux 服务器上运行（因为这是我在我们的地牢中拥有的），但可能的应用程序将是 Windows / Active Directory。

^* 或与其他性能因素（如数据库、消息正文使用 XML 与 JSON 等）相比具有显着性。

^** 如果将来我们希望允许基于浏览器访问 Web 服务，那么 SPNEGO 将是可行的方法。

Answer 1

1. 要回答您的第一个问题，GSS-SPNEGO 可能包括多个往返行程。它不仅限于两个。您应该实现会话处理，并在成功验证后发出一个会话 cookie，客户端应在每个请求上显示该会话 cookie。当这个 cookie 无效时，服务器会强制你重新认证。这样，您只会在真正需要时产生谈判费用。

2. 根据您的应用程序设计，您可以选择不同的身份验证方法。在 FreeIPA 中，我们一直建议使用前端身份验证并允许应用程序重新使用前端确实对用户进行身份验证的事实。有关不同方法的详细说明，请参阅http://www.freeipa.org/page/Web_App_Authentication。

我建议您阅读上面引用的链接，并检查我的同事所做的材料：https://www.adelton.com/ 他是许多 Apache（和 nginx）模块的作者，这些模块有助于在与实际 Web 应用程序一起使用时将身份验证与实际 Web 应用程序分离免费IPA。

Answer 2

在重新阅读我的问题时，我真正提出的问题是：

a) SPNEGO 的开销是否足够大，以至于仅将 if 用于授权是有意义的，并且应该将“其他东西”用于后续服务调用？

或

b) SPNEGO 的开销在更大的方案中是否不重要，并且可以用于所有服务调用？

答案是：视情况而定；找出答案的关键是测量使用和不使用 SPNEGO 的服务调用的性能。

今天我运行了 4 个基本测试用例：

1. 一个简单的“ping”类型的网络服务，没有 SPNEGO
2. 一个简单的“ping”类型的网络服务，使用 SPNEGO
3. 调用应用程序的登录服务，没有 SPNEGO
4. 使用 SPNEGO 调用应用程序的登录服务

每个测试都是从循环 60 秒的 ksh 脚本调用的，并在这段时间内通过 CURL 进行尽可能多的调用。

在我测量的第一次测试运行中：

没有 SPNEGO

• 15 次 ping
• 11 次登录

与 SPENGO

• 8 ping
• 8 次登录

这最初表明使用 SPNEGO 我只能拨打一半的电话。然而，经过反思，即使使用的虚拟机指定不佳，测量的总调用量似乎也很低。

经过一些谷歌搜索和调整后，我重新运行了所有调用 CURL 的测试，并仅针对 IPV4 使用了 -4 标志。这给出了以下内容：

没有 SPNEGO

• 300+ ping
• 100+ 次登录

使用 SPNEGO

• 19 ping
• 14 次登录

这证明了使用和不使用 SPNEGO 的显着差异！

虽然我需要对执行某些后端处理的真实服务进行进一步测试，但这表明在通过 SPNEGO 进行身份验证后的后续服务调用中“使用其他东西”是一个强有力的案例。

Samson 在他的 cmets 中记录了 Hadoop 世界的先例，并添加了高度分布式/可用服务主体的额外架构考虑