注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

写着玩

Bob

 
 
 

日志

 
 
 
 

HTTP authentication  

2010-01-10 22:30:21|  分类: Chrome |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
As specified in RFC 2617, HTTP supports authentication using the WWW-Authenticate request headers and the Authorization response headers (and the Proxy-Authenticate and Proxy-Authorization headers for proxy authentication).

Supported authentication schemes

Our research showed that it is sufficient to support four authentication schemes: Basic, Digest, NTLM, and Negotiate. We already support Basic, Digest, and NTLM, and plan to add support for Negotiate.

The Basic and Digest schemes are specified in RFC 2617. NTLM is a Microsoft proprietary protocol. The Negotiate scheme is specified in RFC 4559 and can be used to negotiate either Kerberos or NTLM.

The remaining work is:
  • support the Negotiate scheme. This needs to use GSS-API on Mac and Linux and SSPI on Windows.
  • automatic logon to intranet sites when NTLM or Negotiate is used. This single-signon-like behavior is important to some users; to them, it is not NTLM without the automatic logon. We need to figure how to determine if a site is on the intranet, or enumerate the intranet sites in a preference as Firefox does.
  • support NTLMv2.  Our portable NTLM code supports NTLMv1 only.
Authentication handler framework

We created the authentication handler framework when we implemented the Basic and Digest authentication schemes. This framework needs to be extended to handle the NTLM and Negotiate schemes, which differ from the Basic and Digest schemes in a few aspects.
  • The NTLM and Negotiate schemes are connection-based (Microsoft calls it session-based). The authentication consists of two rounds of requests and responses over a keep-alive connection. Then, additional requests can be made over that keep-alive connection without authentication.
  • The authentication handlers for Basic and Digest can be shared by multiple transactions, so the handlers can be cached and reused for preemptive authentication. It is not clear whether the authentication handlers for NTLM and Negotiate can be shared because they seem to contain state specific to each transaction, and therefore we can't reuse cached handlers for NTLM and Negotiate.
Choosing an authentication scheme

When a server or proxy accepts multiple authentication schemes, our network stack selects the authentication scheme with the highest score:
  • Basic: 1
  • Digest: 2
  • NTLM: 3
  • Negotiate: 4 (proposed, not yet implemented)
The Basic scheme has the lowest score because it sends the username/password unencrypted to the server or proxy.

So we choose the most secure scheme, and we ignore the server or proxy's preference, indicated by the order in which the schemes are listed in the WWW-Authenticate or Proxy-Authenticate response headers. This could be a source of compatibility problems because MSDN documents that "WinInet chooses the first method it recognizes." Note: In IE7 or later, WinInet chooses the first non-Basic method it recognizes.

Warn about Basic authentication over unencrypted channels

Since the Basic authentication scheme sends the username/password encrypted, we should warn users in the login dialog if we are going to perform Basic authentication over HTTP or to a proxy.
  评论这张
 
阅读(1095)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017