HTTPClient4.5.2学习笔记（四）： HTTP 身份认证

最新推荐文章于 2022-07-04 11:14:48 发布

自然鸟神

最新推荐文章于 2022-07-04 11:14:48 发布

阅读量4.1k

点赞数

分类专栏： HTTPClient4.X

HTTPClient4.X 专栏收录该内容

6 篇文章 2 订阅

订阅专栏

HttpClient提供对HTTP标准规范定义的认证方案以及许多广泛使用的非标准认证方案（如NTLM和SPNEGO）的全面支持

4.1.用户凭证（ User credentials）

用户认证的任何过程都需要一组可用于建立用户身份的凭据。在最简单的用户凭证就是用户名/密码对. UsernamePasswordCredentials 表示一组凭证集合，其中包括一个security principal 和一个明文密码. 该实现对于由HTTP标准规范定义的标准认证方案。

   UsernamePasswordCredentials up=new UsernamePasswordCredentials("user","password");
   // user
    System.out.println(up.getUserPrincipal().getName());
    //user
    System.out.println(up.getUserName());
    //password
    System.out.println(up.getPassword());

NTCredentials是一个Microsoft Windows特定的实现，除了用户名/密码对之外还包括一组额外的Windows特定属性，例如用户域的名称。在Microsoft Windows网络中，同一用户可以属于多个域，每个域具有不同的授权集。

   NTCredentials creds=new NTCredentials("user", "pwd", "workstation", "domain");
    //DOMAIN/user
    System.out.println(creds.getUserPrincipal().getName());
   //pwd
    System.out.println(creds.getPassword());

4.2. 身份认证 schemes（Authentication schemes）

AuthScheme接口表示一种抽象的面向challenge-response的认证方案。认证方案有望支持以下功能：

解析并处理目标服务器响应于对受保护资源的请求发送的challenge
提供已处理challenge的属性: 认证方案的类型和参数，例如：该认证方案适用于（如果可用）的realm
根据实际授权challenge生成给定的凭证集和HTTP请求的授权字符串.

请注意，认证方案可能是有状态的，涉及一系列质询 - 响应交换（challenge-response exchanges，其实这应该是密码学里面的专业术语）

HttpClient 附带了一些 AuthScheme实现 :

Basic: 基本认证方案如RFC 2617所定义。该认证方案不安全，因为凭证以明文形式发送。尽管其不安全性如果与TLS / SSL加密结合使用，则基本认证方案是完全适用的。
Digest. 摘要认证方案如RFC 2617所定义。摘要认证方案比基本安全性更好，对于那些不希望通过TLS / SSL加密实现全传输安全性开销的应用程序，这是一个不错的选择。
NTLM: NTLM是由Microsoft开发的专有认证方案，针对Windows平台进行了优化。 NTLM被认为比Digest更安全。
SPNEGO: SPNEGO（简单和受保护的GSSAPI协商机制）是一个GSSAPI“伪机制”，用于协商一些可能的真实机制之一。 SPNEGO最明显的用途是Microsoft的HTTP协商认证扩展。可协商的子机制包括Active Directory支持的NTLM和Kerberos。目前HttpClient只支持Kerberos子机制。
Kerberos: Kerberos认证实现.

4.3.用户凭证生成器（ Credentials provider）

Credentials providers 旨在维护一组用户凭证，并能够为特定认证范围生成用户凭据。认证范围由主机名，端口号，域名和认证方案名称组成。当与凭证提供者注册凭证时，可以提供通配符（任何主机，任何端口，任何领域，任何方案）而不是具体的属性值。然后，如果无法找到直接匹配，则凭证提供者将被期望能够找到特定范围的最接近的匹配项。

HttpClient可以使用实现CredentialsProvider接口的凭证提供者的任何物理表示。名为BasicCredentialsProvider的默认CredentialsProvider实现是由java.util.HashMap支持的简单实现。

CredentialsProvider credentialsProvider=new BasicCredentialsProvider();
    credentialsProvider.setCredentials(new AuthScope("somehost", AuthScope.ANY_PORT), 
    		                           new UsernamePasswordCredentials("u1","p1"));
    credentialsProvider.setCredentials(new AuthScope("somehost", 8080), 
            new UsernamePasswordCredentials("u2","p2"));
    credentialsProvider.setCredentials(
    	    new AuthScope("otherhost", 8080, AuthScope.ANY_REALM, "ntlm"), 
    	    new UsernamePasswordCredentials("u3", "p3"));
    //[principal: u1]
    System.out.println(credentialsProvider.getCredentials(
    	    new AuthScope("somehost", 80, "realm", "basic")));
    //[principal: u2]
    System.out.println(credentialsProvider.getCredentials(
    	    new AuthScope("somehost", 8080, "realm", "basic")));
    //null
    System.out.println(credentialsProvider.getCredentials(
    	    new AuthScope("otherhost", 8080, "realm", "basic")));
    //[principal: u3]
    System.out.println(credentialsProvider.getCredentials(
    	    new AuthScope("otherhost", 8080, null, "ntlm")));

4.4. HTTP 身份认证和执行上下文

HttpClient依赖于AuthState类来跟踪有关身份验证过程状态的详细信息。HttpClient在HTTP请求执行过程中创建AuthState的两个实例：一个用于目标主机身份验证，另一个用于代理身份验证。如果目标服务器或代理需要用户身份验证，则相应的AuthScope实例将使用认证过程中使用的AuthScope，AuthScheme和Crednetials进行填充。可以检查AuthState，以便找出要求哪种类型的身份验证，是否找到匹配的AuthScheme实现，以及凭据提供程序是否设法找到给定身份验证范围的用户凭据。

在HTTP请求执行过程中，HttpClient将以下与认证相关的对象添加到执行上下文中：

Lookup ：表示实际的认证方案注册表。在本地上下文中设置的此属性的值优先于默认值。
CredentialsProvider：代表实际凭证Provider的实例。在本地上下文中设置的此属性的值优先于默认值。
AuthState ：表示实际的目标认证状态。在本地上下文中设置的此属性的值优先于默认值。
AuthState：表示实际的代理身份验证状态。在本地上下文中设置的此属性的值优先于默认值。
AuthCache：表示实际认证数据高速缓存的实例。在本地上下文中设置的此属性的值优先于默认值。

可以使用本地HttpContext对象来在请求执行之前自定义HTTP认证上下文，或者在执行请求后检查其状态:

CloseableHttpClient httpclient = <...>

CredentialsProvider credsProvider = <...>
Lookup<AuthSchemeProvider> authRegistry = <...>
AuthCache authCache = <...>

HttpClientContext context = HttpClientContext.create();
context.setCredentialsProvider(credsProvider);
context.setAuthSchemeRegistry(authRegistry);
context.setAuthCache(authCache);
HttpGet httpget = new HttpGet("http://somehost/");
CloseableHttpResponse response1 = httpclient.execute(httpget, context);
<...>

AuthState proxyAuthState = context.getProxyAuthState();
System.out.println("Proxy auth state: " + proxyAuthState.getState());
System.out.println("Proxy auth scheme: " + proxyAuthState.getAuthScheme());
System.out.println("Proxy auth credentials: " + proxyAuthState.getCredentials());
AuthState targetAuthState = context.getTargetAuthState();
System.out.println("Target auth state: " + targetAuthState.getState());
System.out.println("Target auth scheme: " + targetAuthState.getAuthScheme());
System.out.println("Target auth credentials: " + targetAuthState.getCredentials());

4.5.缓存身份认证数据

从版本4.1起HttpClient自动缓存有关已成功验证的主机的信息。请注意，必须使用相同的执行上下文来执行逻辑相关的请求，以便缓存的身份验证数据从一个请求传播到另一个请求。一旦执行上下文超出范围，认证数据就会丢失。

4.6. 预先身份认证（Preemptive authentication）

HttpClient不支持preemptive authentication的拆箱功能,因为如果 preemptive authentication使用不当可能导致重大的安全问题，例如以明文形式将用户凭证发送给未经授权的第三方。因此, 在特定的应用环境中，使用者需要事先的权衡一下preemptive authentication好处和带来的安全风险 .

尽管如此，可以通过预先填写认证数据高速缓存来配置HttpClient来抢占。

CloseableHttpClient httpclient = <...>

HttpHost targetHost = new HttpHost("localhost", 80, "http");
CredentialsProvider credsProvider = new BasicCredentialsProvider();
credsProvider.setCredentials(
        new AuthScope(targetHost.getHostName(), targetHost.getPort()),
        new UsernamePasswordCredentials("username", "password"));

// Create AuthCache instance
AuthCache authCache = new BasicAuthCache();
// Generate BASIC scheme object and add it to the local auth cache
BasicScheme basicAuth = new BasicScheme();
authCache.put(targetHost, basicAuth);

// Add AuthCache to the execution context
HttpClientContext context = HttpClientContext.create();
context.setCredentialsProvider(credsProvider);
context.setAuthCache(authCache);

HttpGet httpget = new HttpGet("/");
for (int i = 0; i < 3; i++) {
    CloseableHttpResponse response = httpclient.execute(
            targetHost, httpget, context);
    try {
        HttpEntity entity = response.getEntity();

    } finally {
        response.close();
    }
}

4.7. NTLM 身份认证

从版本4.1开始，HttpClient全面支持NTLMv1，NTLMv2和NTLM2会话认证。仍然可以继续使用外部NTLM引擎，例如由Samba项目开发的JCIFS库作为其Windows互操作性程序套件的一部分。

4.7.1. NTLM 连接持久化

与标准的基本和摘要方案相比，NTLM认证方案在计算开销和性能影响方面要高得多。这可能是微软选择使NTLM认证方案有状态的主要原因之一。也就是说，一旦被认证，用户身份在整个生命周期中与该连接相关联。 NTLM连接的有状态使得连接持久性更加复杂，因为持久的NTLM连接可能不会被具有不同用户身份的用户重新使用的明显原因。HttpClient附带的标准连接管理器完全能够管理状态连接。但是，在同一会话中的逻辑相关请求使用相同的执行上下文以使其知道当前用户身份是至关重要的。否则，HttpClient将最终为针对NTLM保护的资源的每个HTTP请求创建一个新的HTTP连接。有关有状态HTTP连接的详细讨论，请参阅本节。

由于NTLM连接是有状态的，因此通常建议使用比较便捷的方法（如GET或HEAD）触发NTLM身份验证，并重新使用相同的连接来执行更耗时的方法，特别是那些包含请求实体（如POST或PUT）。

CloseableHttpClient httpclient = <...>

CredentialsProvider credsProvider = new BasicCredentialsProvider();
credsProvider.setCredentials(AuthScope.ANY,
        new NTCredentials("user", "pwd", "myworkstation", "microsoft.com"));

HttpHost target = new HttpHost("www.microsoft.com", 80, "http");

// Make sure the same context is used to execute logically related requests
HttpClientContext context = HttpClientContext.create();
context.setCredentialsProvider(credsProvider);

// Execute a cheap method first. This will trigger NTLM authentication
HttpGet httpget = new HttpGet("/ntlm-protected/info");
CloseableHttpResponse response1 = httpclient.execute(target, httpget, context);
try {
    HttpEntity entity1 = response1.getEntity();
} finally {
    response1.close();
}

// Execute an expensive method next reusing the same context (and connection)
HttpPost httppost = new HttpPost("/ntlm-protected/form");
httppost.setEntity(new StringEntity("lots and lots of data"));
CloseableHttpResponse response2 = httpclient.execute(target, httppost, context);
try {
    HttpEntity entity2 = response2.getEntity();
} finally {
    response2.close();
}

4.8. `SPNEGO`/Kerberos 身份认证

SPNEGO（简单和受保护的GSSAPI协商机制）旨在允许对服务进行身份验证，当两方都不知道其他用户可以使用/提供的内容时。最常用于执行Kerberos身份验证。它可以包装其他机制，但是HttpClient中的当前版本只是考虑到Kerberos的设计。

4.8.1. HttpClient`中支持的SPNEGO`

SPNEGO认证方案与Sun Java 1.5及更高版本兼容。但是，强烈建议使用Java> = 1.6，因为它更完全支持SPNEGO身份验证。

Sun JRE提供支持类来完成几乎所有的Kerberos和SPNEGO令牌处理。这意味着很多设置适用于GSS类。 SPNegoScheme是一个简单的类，用于处理编号，并读取和写入正确的标题。

最好的方法是在示例中获取KerberosHttpClient.java文件，并尝试使其正常工作。有很多问题可能会发生，但如果幸运的话，它会工作没有太多的问题。它还应该提供一些调试输出。

在Windows中，应该默认使用登录的凭据; 这可以通过使用“kinit”来覆盖。 $ JAVA_HOME \ bin \ kinit testuser@AD.EXAMPLE.NET，这对于测试和调试问题非常有帮助。删除由kinit创建的缓存文件，以恢复到Windows Kerberos缓存。

确保在krb5.conf文件中列出domain_realms。这是问题的主要来源。

4.8.2. GSS/Java Kerberos 设置

本文档假设您正在使用Windows，但大部分信息也适用于Unix。

org.ietf.jgss类有很多可能的配置参数，主要在krb5.conf / krb5.ini文件中。更多关于格式的信息http://web.mit.edu/kerberos/krb5-1.4/krb5-1.4.1/doc/krb5-admin/krb5.conf.html.

客户端Web浏览器为资源提供HTTP GET
Web服务器返回HTTP 401状态和标题：WWW-Authenticate：Negotiate
客户端生成一个NegTokenInit，base64对其进行编码，并使用授权头重新提交GET：授权：协商<base64 encoding>。
服务器解码NegTokenInit，提取支持的MechTypes（仅适用于我们的Kerberos V5），确保它是预期的之一，然后提取MechToken（Kerberos令牌）并进行身份验证。

如果需要更多的处理，另一个HTTP 401将返回给具有WWW-Authenticate头中更多数据的客户端。客户端获取信息并生成另一个令牌，将其传回授权标头，直到完成。
当客户端被认证后，Web服务器应该返回HTTP 200状态，最终的WWW-Authenticate标头和页面内容。

4.8.3. `login.conf` 文件配置

以下配置是在Windows XP中针对IIS和JBoss协商模块的基本设置。

系统属性java.security.auth.login.config可用于指向login.conf文件。

login.conf内容可能如下所示：

com.sun.security.jgss.login {
  com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true;
};

com.sun.security.jgss.initiate {
  com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true;
};

com.sun.security.jgss.accept {
  com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true;
};

4.8.4. `krb5.conf` / `krb5.ini` 文件配置

如果未指定，将使用系统默认值。如果需要，可以通过将系统属性java.security.krb5.conf设置为指向自定义krb5.conf文件来覆盖。

krb5.conf内容可能如下所示：

[libdefaults]
    default_realm = AD.EXAMPLE.NET
    udp_preference_limit = 1
[realms]
    AD.EXAMPLE.NET = {
        kdc = KDC.AD.EXAMPLE.NET
    }
[domain_realms]
.ad.example.net=AD.EXAMPLE.NET
ad.example.net=AD.EXAMPLE.NET

4.8.5. Windows 配置规范

要允许Windows使用当前user's tickets，系统属性javax.security.auth.useSubjectCredsOnly必须设置为false，并且Windows注册表项allowtgtsessionkey应该被正确添加和设置，以允许在Kerberos票证授予中发送会话密钥票。

在Windows Server 2003和Windows 2000 SP4上，以下是必需的注册表设置：

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Value Name: allowtgtsessionkey
Value Type: REG_DWORD
Value: 0x01

以下是Windows XP SP2上注册表设置的位置：

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\
Value Name: allowtgtsessionkey
Value Type: REG_DWORD
Value: 0x01

自然鸟神

关注

0
点赞
踩
5

收藏

觉得还不错? 一键收藏
0
评论
HTTPClient4.5.2学习笔记（四）： HTTP 身份认证

HttpClient提供对HTTP标准规范定义的认证方案以及许多广泛使用的非标准认证方案（如NTLM和SPNEGO）的全面支持4.1.用户凭证（ User credentials）用户认证的任何过程都需要一组可用于建立用户身份的凭据。在最简单的用户凭证就是用户名/密码对.UsernamePasswordCredentials 表示一组凭证集合，其中包括一个sec
复制链接

扫一扫