-1

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

那么有什么关系呢？:)

4

2 回答 2

1

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

已知一些非标准的 HTTP 扩展（例如，[RFC4559]）违反了这个要求，导致安全和互操作性问题

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

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

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

你的困惑是有道理的。

于 2021-12-19T19:29:25.313 回答
0

来自RFC 7235

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

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

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

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

于 2014-08-11T02:24:50.060 回答