HTTP规范:代理授权和授权标头

Question

所以我试图实现以下场景:

• 应用程序受基本身份验证保护.让我们说它是托管的app.com
• 在应用程序前面的HTTP代理也需要身份验证.它托管在proxy.com

因此,用户必须在同一请求中为代理和应用程序提供凭证,因此他具有不同的用户名/密码对:一对用于对应用程序进行身份验证,另一对用户/密码对用于对代理进行身份验证.

阅读规范后,我不确定我应该如何实现这一点.我想要做的是:

1. 用户向代理发出HTTP请求,而不进行任何类型的身份验证.
2. 代理回答407 Proxy Authentication Required并返回Proxy-Authenticate以下格式的标头:"Proxy-Authenticate: Basic realm="proxy.com".
   问题:此Proxy-Authenticate标题是否正确设置？
3. 然后,客户端使用Proxy-Authorization标头重试请求,该标头是代理的Base64表示username:password.
4. 这次代理验证请求,但随后应用程序使用401 Unauthorized标头进行应答.用户由代理进行身份验证,但不是由应用程序进行身份验证.应用程序WWW-Authenticate为响应添加标题WWW-Authenticate: Basic realm="app.com".问题:这个标题值是对的吗？
5. 客户端再次使用Proxy-Authorization标头和使用Authorization应用程序的Base64表示值的标头重试请求username:password.
6. 此时,代理成功验证请求,将请求转发给对用户进行身份验证的应用程序.客户终于得到了回复.

整个工作流程是否正确？

Answer 1

是的,对于您描述的情况,这看起来像是一个有效的工作流程,并且那些Authenticate标头看起来格式正确.

值得注意的是,尽管不太可能,给定连接可能涉及链接在一起的多个代理,并且每个代理本身都需要身份验证.在这种情况下,每个中间代理的客户端本身将返回一条407 Proxy Authentication Required消息,并自己用Proxy-Authorization头重复请求; 在Proxy-Authenticate和Proxy-Authorization标头是没有得到从一台服务器传递到下一个单跳头,但WWW-Authenticate并Authorization是被认为是从客户端到服务器的最后端至端头,通过逐字通过了中间人.

由于该Basic方案以明文形式发送密码(base64是可逆编码),因此最常用于SSL.此方案以不同的方式实现,因为希望防止代理看到发送到最终服务器的密码:

• 客户端打开到代理的SSL通道以启动请求,但是它不会提交常规HTTP请求,而是提交特殊CONNECT请求(仍带有Proxy-Authorization标头)以打开到远程服务器的TCP隧道.
• 然后,客户端继续创建另一个嵌套在第一个 SSL通道内的SSL通道,通过该通道传输包括Authorization标头的最终HTTP消息.

在这种情况下,代理只知道客户端连接到的主机和端口,而不知道通过内部SSL通道传输或接收的内容和端口.此外,嵌套通道的使用允许客户端"看到"代理和服务器的SSL证书,允许对两者的身份进行身份验证.