`
ugibb510
  • 浏览: 130439 次
  • 性别: Icon_minigender_1
  • 来自: 北京
文章分类
社区版块
存档分类
最新评论

转:Basic and Digest Access Authentication (rfc2617) 及HttpClient实现

 
阅读更多

转:http://www.cnblogs.com/jcli/archive/2012/12/11/2812459.html

 

介绍Basic和Digest

http协议并没有定义相关的安全认证方面的标准,所以就有了Basic and Digest Access Authentication的定义来补充,它的目的就是补充一套基于http服务端的认证机制,保护相关的资源避免被非法用户访问,如果你要访问被保护的资源,则必需要提供合法的用户名和密码。

和https有什么关联?

basic & digest auth 和 https 没有任何关系。前者是为用户认证机制,后者是信息通道加密措施。

basic 和 digest有什么区别?

digest是basic的升级版,更加安全。因为basic是明文传输密码信息,而digest是加密后传输。

digest就是绝对安全的吗?

首先,这个世界上没有绝对的东西。digest默认用MD5(其它算法也可以)对密码进行加密,虽然相比basic认证的明文传输更安全,但是加密算法本身的安全性也值得怀疑(md5是可以反推出原文的)。再者,digest只是对认证信息的加密,后续的内容传输安全性得不到保障。所以https机制的作用就显现出来。

通过上面的相关信息,我们可以得到一个清晰的结论:如果你想加强自己的认证信息的保护,有两种选择,一是基于digest认证;别一种是在https通道上进行basic认证。

basic和digest认证流程

 

 

1,客户端请求受保护的资源
2,服务器检测到没有授权,则生成一个challenge返回给客户端
3,客户端根据challenge和相关信息计算出digest
4,附带3计算出的信息再次请求1中的资源
5,服务端根据已知的用户密码信息计算出digest并与4中请求的digest比较验证
6,服务端验证通过后返回资源给合法用户

Basic和Digest的认证都是按照上面的流程来,唯一不同的是3和5中计算digest的算法不同:Basic是将密码直接base64编码(明文),而Digest是用MD5进行加密后传输。

下面假设我们现在要请求:http://localhost:8080/index.html 这个路径,而它需要认证后才能访问。


Basic的流程如下:

  1. 在浏览器请求:http://localhost:8080/index.html
  2. 服务器返回401(unauthentication)代码,并附带一个包含challenge的头,格式如下:WWW-Authenticate    Basic realm="Admin All"
  3. 浏览器用:base64(username:password) 编码后的信息添加到请求头中再次请求1中的资源,如果用户名是tomcat,密码是tomcat,则base64(tomcat:tomcat)为(dG9tY2F0OnRvbWNhdA==)。所以头信息为:Authorization    Basic dG9tY2F0OnRvbWNhdA==
  4. 用3中计算的请求头信息再次请求1中的资源
  5. 服务器用3中相同的算法(base64)验证用户密码合法性
  6. 返回index.html的资源

Digest的流程和上面一样,只是challenge和digest的生成算法不同

  1. 在浏览器请求:http://localhost:8080/index.html
  2. 服务器返回401(unauthentication)代码,并附带一个包含challenge的头,格式如下:WWW-Authenticate    Digest realm="Admin All", qop="auth", nonce="1354760194666:4465c7b1921b6d769fd359e5152c453f", opaque="EE9C283E89AFB63E7FF6E2C04C524807"
  3. 浏 览器用MD5编码后的信息添加到请求头中再次请求1中的资源,如果用户名是tomcat,密码是tomcat,则生成的头信息:Authorization    Digest username="tomcat", realm="Admin All", nonce="1354760194666:4465c7b1921b6d769fd359e5152c453f", uri="/web/index.html", response="8d30e6438636fe21c6045246dd034372", opaque="EE9C283E89AFB63E7FF6E2C04C524807", qop=auth, nc=00000001, cnonce="9201a828891792b9"
  4. 用3中计算的请求头信息再次请求1中的资源
  5. 服务器用3中相同的算法(base64)验证用户密码合法性
  6. 返回index.html的资源

这里我们只是讨论流程,具体的challenge和digest的生成算法请参考:RFC2617

HttpClient的实现

示例代码:

HttpHost targetHost = new HttpHost("localhost", 8080);

		DefaultHttpClient client = new DefaultHttpClient();

		HttpContext context = new BasicHttpContext();
		context.setAttribute(ClientContext.CREDS_PROVIDER,
				new BasicCredentialsProvider());
		CredentialsProvider provider = (CredentialsProvider) context
				.getAttribute(ClientContext.CREDS_PROVIDER);
		provider.setCredentials(new AuthScope(targetHost.getHostName(),
				targetHost.getPort()), new UsernamePasswordCredentials("tomcat", "admin"));

		HttpGet get = new HttpGet("http://localhost:8080/web/Hello");
		HttpResponse response = client.execute(get, context);
		System.out.println(response.getStatusLine());
		HttpEntity entity = response.getEntity();
		String s = EntityUtils.toString(entity);
		System.out.println(s);

 

主要类结构图:

 

 

Auth流程图:

 

 

 

 

 

 

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics