不带.NET的Windows身份验证标头.可能的? [英] Windows Authentication Headers without .NET. Possible?

问题描述

我想知道是否有人知道一种无需在ASP站点上托管就可以使用Windows身份验证的方法.它是可访问LDAP的Intranet，所以我想知道是否有一种方法可以强制客户端向我提供数据，就像它来自ASP站点一样.我只需要登录域和用户名，就可以从那里运行.在Ubuntu上使用Node.js.有人对此有任何经验吗?

I was wondering if anyone knew of a way to use Windows Authentication without hosting on an ASP site. It's an intranet w/ access to LDAP, so I'm wondering if there's a way to force the client to provide me the data as if it was coming from an ASP site. I just need the login domain and username and I can run from there. Using Node.js on Ubuntu. Anyone have any experience with this?

推荐答案

更新:现在有实现Windows集成身份验证的模块.

在401响应中，您需要提供一个WWW-Authenticate标头，其值为NTLM，该标头告知浏览器他们需要发送Windows凭据.

In your 401 response, you need to provide a WWW-Authenticate header with a value of NTLM, which informs browsers that they need to send Windows credentials.

response.writeHead(401, {
    'WWW-Authenticate': 'NTLM',
});

然后，您将获得实现NTLM身份验证的乐趣.引用有关NTLM身份验证协议的文档:

You then have the fun of implementing NTLM authentication. Quoting from this document about the NTLM authentication protocol:

1. 客户端从服务器请求受保护的资源:

1. The client requests a protected resource from the server:

GET /index.html HTTP/1.1

服务器以401状态响应，指示客户端必须进行身份验证.通过WWW-Authenticate标头将NTLM表示为受支持的身份验证机制.通常，服务器此时会关闭连接:

The server responds with a 401 status, indicating that the client must authenticate. NTLM is presented as a supported authentication mechanism via the WWW-Authenticate header. Typically, the server closes the connection at this time:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM
Connection: close

请注意，如果Internet Explorer是第一个提供的机制，它将仅选择NTLM；否则，它将选择NTLM.这与RFC 2616不一致，RFC 2616指出客户端必须选择支持最强的身份验证方案.

Note that Internet Explorer will only select NTLM if it is the first mechanism offered; this is at odds with RFC 2616, which states that the client must select the strongest supported authentication scheme.

客户端使用Authorization标头重新提交请求，该标头包含类型1消息参数. Type 1消息是Base-64编码的，用于传输.从这一点开始，连接保持打开状态.关闭连接需要重新认证后续请求.这意味着服务器和客户端必须通过HTTP 1.0样式的"Keep-Alive"标头或HTTP 1.1(默认情况下采用持久连接)来支持持久连接.相关的请求标头显示如下:

The client resubmits the request with an Authorization header containing a Type 1 message parameter. The Type 1 message is Base-64 encoded for transmission. From this point forward, the connection is kept open; closing the connection requires reauthentication of subsequent requests. This implies that the server and client must support persistent connections, via either the HTTP 1.0-style "Keep-Alive" header or HTTP 1.1 (in which persistent connections are employed by default). The relevant request headers appear as follows:

GET /index.html HTTP/1.1
Authorization: NTLM TlRMTVNTUAABAAAABzIAAAYABgArAAAACwALACAAAABXT1JLU1RBVElPTkRPTUFJTg==

服务器以401状态答复，其中包含类型2消息在WWW-Authenticate标头中(再次，使用Base-64编码).如下所示.

The server replies with a 401 status containing a Type 2 message in the WWW-Authenticate header (again, Base-64 encoded). This is shown below.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM TlRMTVNTUAACAAAADAAMADAAAAABAoEAASNFZ4mrze8AAAAAAAAAAGIAYgA8AAAARABPAE0AQQBJAE4AAgAMAEQATwBNAEEASQBOAAEADABTAEUAUgBWAEUAUgAEABQAZABvAG0AYQBpAG4ALgBjAG8AbQADACIAcwBlAHIAdgBlAHIALgBkAG8AbQBhAGkAbgAuAGMAbwBtAAAAAAA=

客户端通过使用Authorization标头重新提交请求来响应类型2消息，该标头包含以Base-64编码的

The client responds to the Type 2 message by resubmitting the request with an Authorization header containing a Base-64 encoded Type 3 message:

GET /index.html HTTP/1.1
Authorization: NTLM TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAwADABAAAAACAAIAEwAAAAWABYAVAAAAAAAAACaAAAAAQIAAEQATwBNAEEASQBOAHUAcwBlAHIAVwBPAFIASwBTAFQAQQBUAEkATwBOAMM3zVy9RPyXgqZnr21CfG3mfCDC0+d8ViWpjBwx6BhHRmspst9GgPOZWPuMITqcxg==

最后，服务器会验证客户端的Type 3消息中的响应，并允许访问资源.

Finally, the server validates the responses in the client's Type 3 message and allows access to the resource.

 HTTP/1.1 200 OK

---

获取用户的用户名应该很容易–它以纯文本形式在Type 3消息中发送.实际验证他们是否提供了正确的密码完全是另一回事.实施所有这些操作留给读者练习.

---

It should be easy enough to get the user's username – it's sent as plain text in the Type 3 message. Actually validating that they've supplied the correct password is another matter entirely. Implementing all of this is left as an exercise for the reader.

这篇关于不带.NET的Windows身份验证标头.可能的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！