SPNEGO：成功协商和认证后的后续呼叫

Question

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

持有有效Kerberos票证授予票证（TGT）的用户可以调用启用SPNEGO的Web服务，客户端和服务器将进行协商，用户将通过Kerberos和应用程序级别进行身份验证，并且（在成功身份验证后）在其票证缓存中拥有我的服务主体的服务票证。

这可以很好地使用带有--协商标志的CURL作为测试客户端。

在第一次通过时，CURL会发出一个没有特殊标头的普通HTTP请求。此请求被服务器拒绝，服务器会在响应标头中添加“WWW-Authenticate： Nealog ate”，建议进行协商。然后，CURL从KDC获取一个Service Ticket，并发出第二个请求，这次使用在请求标头中协商包装好的Service Ticket（NigTokenInit）服务器然后打开票证，对用户进行身份验证，并且（如果身份验证成功）执行请求的服务（例如登录）。

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

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

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

为什么每个Firefox请求的授权行都会更改？

为什么Firefox一直在协商kerberos服务票证？

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

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的OELLinux服务器上运行（因为这是我在我们的地下城中拥有的），但可能的应用程序将是Windows/Active Directory。

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

如果将来我们希望允许基于浏览器访问web服务，那么SPNEGO将是一条可行的道路。

Answer 1

在重读我的问题时，我真正想问的问题是：

a） SPNEGO的开销是否足够大，以至于仅将其用于授权，并且“其他”应用于后续服务调用？

或

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

答案是：视情况而定；找到答案的关键是衡量有无SPNEGO的服务调用的性能。

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

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

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

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

无SPNEGO

• 15 ping
• 11次登录

与SPENGO合作

• 8 ping
• 8个登录

这最初表明，使用SPNEGO我只能拨打一半的电话。然而，经过深思熟虑，即使考虑到所使用的虚拟机没有得到很好的指定，测得的总调用量也似乎很低。

在进行了一些google和调优之后，我重新运行了所有调用CURL的测试，其中只对IPV4使用了-4标志。由此得出以下结论：

无SPNEGO

• 300 ping
• 100次登录

与SPNEGO

• 19 ping
• 14次登录

这表明了有无SPNEGO的显著差异！

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

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

Answer 2

>

要回答您的第一个问题，GSS-SPNEGO可能包括多次往返。它不限于两次。您应该实现会话处理，并在成功身份验证后发出客户端应在每个请求中呈现的会话cookie。当此cookie无效时，服务器会强制您重新进行身份验证。这样，您只会在真正需要时产生谈判成本。

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

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