SPNEGO：成功协商和身份验证后的后续呼叫 [英] SPNEGO: Subsequent Calls after a Successful Negotiation and Authentication
问题描述
在过去的几天里，我使用 GSS-API 和 SPNEGO 构建了概念验证演示。目的是通过Http RESTful Web服务为用户提供对我们的自定义应用程序服务器提供的服务的单点登录访问。
Over the last few days I have built a proof-of-concept demo using the GSS-API and SPNEGO. The aim is to give users single-sign-on access to services offered by our custom application server via Http RESTful web-services.
持有有效Kerberos票证授予的用户Ticket（TGT）可以调用启用SPNEGO的Web服务，客户端和服务器将协商，
将对用户进行身份验证（由Kerberos和应用程序级别进行身份验证），并且（在成功身份验证时）将具有服务票证我的服务负责人在他的票务缓存中。
A user holding a valid Kerberos Ticket Granting Ticket (TGT) can call the SPNEGO enabled web-service, the Client and Server will negotiate, the user will be authenticated (both by Kerberos and on application level), and will (on successful authentication) have a Service Ticket for my Service Principal in his Ticket Cache.
使用 CURL 并使用--negotiate标志作为测试客户端时，这很有效。
This works well using CURL with the --negotiate flag as a test client.
在第一次传递时，CURL发出没有特殊标头的普通HTTP请求。该请求被服务器拒绝，
将WWW-Authenticate：Negotiate添加到响应头，表明协商。
CURL然后从KDC获得服务票证，并发出第二个请求，这次是Negotiate +请求头中的包装服务票证（NegTokenInit）
然后服务器解开票证，验证用户身份，和（如果验证成功）执行所请求的服务（例如登录）。
On a first pass CURL makes a normal HTTP request with no special headers. This request is rejected by the Server, which adds "WWW-Authenticate: Negotiate" to the response headers, suggesting negotiation. CURL then gets a Service Ticket from the KDC, and makes a second request, this time with Negotiate + the wrapped Service Ticket in the request header (NegTokenInit) The Server then unwraps the ticket, authenticates the user, and (if authentication was successful) executes the requested service (e.g. login).
问题是，从客户端到后续服务调用会发生什么服务器？ 客户端现在有一个有效的Kerberos服务票证，但是使用SPNEGO通过CURL进行的其他调用会产生上述相同的两个传递。
The question is, what should happen on subsequent service calls from the client to the server? The client now has a valid Kerberos Service Ticket, yet additional calls via CURL using SPNEGO makes the same two passes described above.
在我看来，我有很多选择：
As I see it, I have a number of options:
1）每个服务调用重复完整的2遍SPNEGO协商（如CURL所做的那样）。
虽然这可能是最简单的选择，但至少在理论上会有一些开销：客户端和服务器都在创建和拆除GSS上下文，并且请求通过网络发送两次，对于GET可能没问题，如下面的问题所讨论的那样，对于POST来说则更少：
1) Each service call repeats the full 2 pass SPNEGO negotiation (as CURL does). While this maybe the simplest option, at least in theory there will some overhead: both the client and the server are creating and tearing down GSS Contexts, and the request is being sent twice over the network, probably ok for GETs, less so for POSTs, as discusses in the questions below:
< a href =https://stackoverflow.com/questions/2098077/why-firefox-keeps-negotiating-kerberos-service-tickets?rq=1>为什么Firefox会继续协商kerberos服务票？
但现实生活中的开销 * 是否明显？我想只有性能测试才会知道。
But is the overhead* noticeable in real-life? I guess only performance testing will tell.
2）第一个呼叫使用SPNEGO协商。成功通过身份验证后，后续调用将使用应用程序级别身
这似乎是Websphere Application Server采用的方法，后者使用轻量级第三方认证（LTPA）安全令牌进行后续调用。
2) The first call uses SPNEGO negotiation. Once successfully authenticated, subsequent calls use application level authentication. This would seem to be the approach taken by Websphere Application Server, which uses Lightweight Third Party Authentication (LTPA) security tokens for subsequent calls.
最初这似乎是有点奇怪。成功协商Kerberos可以使用，为什么还要回归其他东西？另一方面，如果GSS-API / SPNEGO可以显示导致明显的开销/性能损失，则此方法可能有效。
Initially this seems to be a bit weird. Having successfully negotiated that Kerberos can be used, why fall back to something else? On the other hand, this approach might be valid if GSS-API / SPNEGO can be shown to cause noticeable overhead / performance loss.
3）第一个呼叫使用SPNEGO协商。成功通过身份验证并信任后，后续调用将使用GSS-API Kerberos。
在这种情况下，我不妨做下面的选项4）。
3) The first call uses SPNEGO negotiation. Once successfully authenticated and trusted, subsequent calls use GSS-API Kerberos. In which case, I might as well do option 4) below.
4）转储SPNEGO，使用纯GSS-API Kerberos。
我可以通过自定义Http标头或cookie交换Kerberos门票。
4) Dump SPNEGO, use "pure" GSS-API Kerberos. I could exchange the Kerberos tickets via custom Http headers or cookies.
有最佳做法吗？
作为背景：客户端和服务器应用程序都在我的控制之下，两者都是用java实现的，我知道两者都说Kerberos。
我选择SPNEGO作为概念验证的开始之地，并选择进入Kerberos和Single Sign On的世界，但这并不是一项艰难的要求。
As background: Both the client and server applications are under my control, both are implemented in java, and I know both "speak" Kerberos. I chose SPNEGO as "a place to start" for the proof-of-concept, and for worming my way into the world of Kerberos and Single Sign On, but it is not a hard requirement.
概念验证在带有FreeIPA的OEL Linux服务器上运行（因为这就是我在地牢中所拥有的），但可能的应用程序将是Windows / Active Directory。
The proof-of-concept runs on OEL Linux servers with FreeIPA (because that is what I have in our dungeons), but the likely application will be Windows / Active Directory.
* 或与其他性能因素相比显着，例如数据库，使用XML与邮件正文的JSON等。
* or significant compared to other performance factors such as the database, use of XML vs JSON for the message bodies etc.
** 如果将来我们希望允许基于浏览器访问Web服务，那么SPNEGO将是您的最佳选择。
** If in the future we wanted to allow browser based access to the web services, then SPNEGO would be the way to go.
推荐答案
-
要回答您的第一个问题，GSS-SPNEGO可能包括多次往返。它不仅限于两个。您应该实现会话处理，并在成功验证后发出客户端应在每个请求上呈现的会话cookie。当此cookie无效时，服务器将强制您重新进行身份验证。这样，只有在真正需要时才会产生协商成本。
To answer your first question, GSS-SPNEGO may include multiple round trips. It is not limited to just two. You should implement a session handling and upon successful authentication issue a session cookie that client should be presenting on each request. When this cookie is invalid, server would force you to re-authenticate. This way you would only incur negotiate costs when that is really needed.
根据您的应用程序设计，您可以选择不同的身份验证方法。在FreeIPA中，我们一直建议进行前端身份验证，并允许应用程序重用前端对用户进行身份验证的事实。有关不同方法的详细说明，请参见 http://www.freeipa.org/page/Web_App_Authentication 。
Depending on your application design you can choose different approaches for authentication. In FreeIPA we have been recommending to have a front-end authentication and allow applications to re-use the fact that front-end did authenticate the user. See http://www.freeipa.org/page/Web_App_Authentication for detailed description of different approaches.
我建议你阅读上面提到的链接，并检查我的同事所做的材料： https://www.adelton.com/ 他是许多Apache（和nginx）模块的作者，与FreeIPA一起使用时，将身份验证与实际Web应用程序分离。
I would recommend you to read the link referenced above and also check materials done by my colleague: https://www.adelton.com/ He is author of a number of Apache (and nginx) modules that help to decouple authentication from actual web applications when used with FreeIPA.
这篇关于SPNEGO：成功协商和身份验证后的后续呼叫的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
