在过去的几天里，我使用 GSS-API 和 SPNEGO 构建了概念验证演示。目的是通过Http RESTful Web服务为用户提供对我们的自定义应用程序服务器提供的服务的单点登录访问。
持有有效Kerberos票证授予票证（TGT）的用户可以调用启用SPNEGO的Web服务，客户端和服务器将进行协商， 用户将通过Kerberos和应用程序级别进行身份验证，并且（在成功身份验证时）将在其故障单缓存中为我的服务主体提供服务故障单。
使用 CURL 并使用--negotiate标记作为测试客户端时，此方法效果很好。
在第一次传递时，CURL会生成一个没有特殊标头的普通HTTP请求。该请求被服务器拒绝， 这增加了＆＃34; WWW-Authenticate：Negotiate＆＃34;到响应头，建议谈判。 然后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）安全令牌进行后续调用。
最初这似乎有点奇怪。成功协商Kerberos可以使用，为什么还要回归其他东西？另一方面，如果可以证明GSS-API / SPNEGO会导致明显的开销/性能损失，则此方法可能有效。
3）第一个呼叫使用SPNEGO协商。成功通过身份验证并信任后，后续调用将使用GSS-API Kerberos。 在这种情况下，我不妨在下面做选项4）。
4）转储SPNEGO，使用＆＃34; pure＆＃34; GSS-API Kerberos。 我可以通过自定义Http标头或cookie交换Kerberos票证。
有最佳做法吗？
作为背景：客户端和服务器应用程序都在我的控制之下，两者都是用java实现的，我知道两者都是＆＃34;说＆＃34; Kerberos的。 我选择了SPNEGO作为＃34;一个开始的地方＆＃34;为了概念验证，以及为了进入Kerberos和Single Sign On的世界而努力，但这并不是一项艰难的要求。
概念验证在带有FreeIPA的OEL Linux服务器上运行（因为这是我在我们的地牢中所拥有的），但可能的应用程序将是Windows / Active Directory。
* 或与其他性能因素（如数据库，使用XML与JSON等消息体等）相比具有显着性。
** 如果将来我们希望允许基于浏览器访问Web服务，那么SPNEGO将是您的最佳选择。
答案 0 :(得分：2)
要回答您的第一个问题，GSS-SPNEGO可能会包含多次往返。它不仅限于两个。您应该实现会话处理，并在成功验证后发出客户端应在每个请求上呈现的会话cookie。当此cookie无效时，服务器将强制您重新进行身份验证。这样，只有在真正需要时才会产生谈判费用。
根据您的应用程序设计，您可以选择不同的身份验证方法。在FreeIPA中，我们一直建议进行前端身份验证，并允许应用程序重用前端对用户进行身份验证的事实。有关不同方法的详细说明，请参阅http://www.freeipa.org/page/Web_App_Authentication。
我建议你阅读上面引用的链接，并检查我的同事完成的材料：https://www.adelton.com/他是许多Apache（和nginx）模块的作者，这些模块有助于在实际的Web应用程序中解析身份验证。与FreeIPA一起使用。
答案 1 :(得分：0)
在重新阅读我的问题时，我真正问的问题是：
a）SPNEGO的开销是否足够大，使用if仅用于授权，以及＆＃34;其他内容＆＃34;应该用于后续服务电话吗？
或
b）SPNEGO的开销在更大的方案中是否显着，并且可以用于所有服务调用？
答案是：这取决于具体情况;并且发现的关键是用SPNEGO来衡量服务呼叫的性能。
今天我运行了4个基本测试用例：
从循环60秒的ksh脚本调用每个测试，并在此时通过CURL进行尽可能多的调用。
在第一次测试中我测量了：
没有SPNEGO
使用SPENGO
这最初表明使用SPNEGO我只能拨打一半的电话。但是，经过反思，即使使用了指定不当的虚拟机，测量的总呼叫量似乎也很低。
经过一些谷歌搜索和调整，我重新调用所有测试调用CURL只有IPV4的-4标志。这给出了以下内容：
没有SPNEGO
使用SPNEGO
这证明了SPNEGO和没有SPNEGO的显着差异！
虽然我需要对进行后端处理的实际服务进行进一步测试，但这表明有一个强有力的理由来使用其他东西＆＃34;通过SPNEGO进行身份验证后的后续服务调用。
在他的评论中，Samson记录了Hadoop世界的先例，并增加了高度分布/可用服务主体的额外架构考虑