Negotiate HTTP 认证机制如何建立会话？答案

【问题标题】：How does the Negotiate HTTP authentication mechanism establish a session?Negotiate HTTP 认证机制如何建立会话？
【发布时间】：2014-10-03 18:25:30
【问题描述】：

如RFC 4559 中所述，Negotiate 机制可能需要多个请求来完成一个 GSSAPI 上下文。但是，我无法从 RFC 中了解使用什么机制将这些请求相互关联。以 RFC 第 5 节中描述的示例为例：

1:
  C: GET dir/index.html

2:
  S: HTTP/1.1 401 Unauthorized
  S: WWW-Authenticate: Negotiate

3:
  C: GET dir/index.html
  C: Authorization: Negotiate a87421000492aa874209af8bc028

4:
  S: HTTP/1.1 401 Unauthorized
  S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356

5:
  C: GET dir/index.html
  C: Authorization: Negotiate 89a8742aa8729a8b028

在第 5 步之前我很清楚。假设可能有许多客户端同时进行身份验证，服务器如何知道第 5 步中的 Authorization 标头是对第 4 步数据的响应？我看不到任何关于会话 cookie 或任何内容的提及，虽然我不是 GSSAPI 专家，但我认为 GSSAPI 数据中没有任何固有的东西可用于将其与身份验证会话相关联。

那么交易是什么？ :)

【问题讨论】：

您需要解密协商数据才能知道它到底是什么。那肯定会给你答案……
@AlexisWilke：但是 GSSAPI 数据对于 GSSAPI 的用户来说应该是不透明的。但是，即使我要打破抽象并对其进行解密，我也非常怀疑它是否包含任何类型的会话 ID。

标签： http http-authentication http-negotiate

【解决方案1】：

使用 TCP 连接维护状态。 RFC-4559 没有直接说明这一点，可能是因为它会让作者感到肮脏。但是在第 6 节讨论“基于会话的身份验证”时，当涉及到代理时，它们同样避开了。在讨论 HTTP 应该如何成为无状态协议时，RFC-7230 第 2.3 节的最后一段中也“呼吁”了这一要求：

已知某些非标准 HTTP 扩展（例如 [RFC4559]）会违反此要求，从而导致安全性和互操作性问题

第 6 节最后一段中的另一个要求更加含糊：

当对客户端提供的数据（例如 PUT 和 POST）使用 SPNEGO HTTP 身份验证工具时，客户端和服务器之间的身份验证应该在发送用户数据之前完成。 gss_init_security_context 的返回状态将指示安全上下文已完成。至此，数据就可以发送到服务器了。

所以服务器应该记住上下文成功完成后的身份验证状态（并向客户端发送带有最后一个令牌的 200），以允许包含实际有效负载的最后一个请求？

你的困惑是有道理的。

【讨论】：

我想知道是否可能不是这种情况，但我不想接受它，除非我找到了对它的明确引用，我从来没有这样做过。然而，RFC 7230 中的那一段似乎与我希望的一样清楚，除了在 RFC 4559 中明确说明之外。多么不幸。

【解决方案2】：

来自RFC 7235

5.1.2。新身份验证方案的注意事项

HTTP 身份验证框架的某些方面限制新的身份验证方案如何工作：

o HTTP 身份验证被假定为无状态：所有必须提供验证请求所需的信息在请求中，而不是依赖于服务器记住先前的请求。基于或绑定到的身份验证底层连接超出了本规范的范围和固有缺陷，除非采取措施确保连接不能被任何一方以外的任何一方使用经过身份验证的用户（参见 [RFC7230] 的第 2.3 节）。

这就是我的记忆，但我想确定一下。因此，用户发送的每个请求都包含所有必要的凭据。服务器本身对身份验证是什么一无所知。它只是询问凭据是否有效，如果答案是肯定的，则继续请求。

【讨论】：

对不起，如果我很密集，但我真的不明白这是如何回答这个问题的。它似乎只是在验证它是一个谜，不是吗？ :)
身份验证隐藏在发送的“奇怪”号码中，每次客户端向服务器发送请求时。换句话说，服务器 (Apache) 不需要有会话 ID，因为您每次都根据需要发送必要的身份验证数据。
你好像误会了。我要问的不是身份验证完成后服务器将来如何识别客户端，而是它如何在身份验证期间，因为Negotiate 身份验证不同于Basic 或@987654324 @，可能需要多个请求才能完成。引用 RFC：“如果上下文不完整，服务器将使用包含 gssapi-data 的 WWW-Authenticate 标头响应 401 状态代码。客户端将解码 gssapi-data，将其传递给 Gss_Init_security_context ，并将新的 gssapi-data 返回到服务器。”