问题标签 [negotiate]

iOS 应用程序是否支持“协商”HTTP 身份验证方案？

我正在尝试访问使用此身份验证方案的服务器。我目前正在使用 ASIHTTPRequest 类，它在内部使用 CFNetwork 库。身份验证失败，并且通过 ASIHTTPRequest 代码跟踪我看到它在通过调用 CFHTTPAuthenticationCreateFromResponse 函数创建的 CFHTTPAuthentication 对象未能通过 CFHTTPAuthenticationIsValid 函数检查后失败。返回的错误是“kCFStreamErrorHTTPAuthenticationTypeUnsupported = -1000”。它用于尝试创建 CFHTTPAuthentication 的响应具有“WWW-Authenticate = Negotiate”标头。这让我觉得不支持协商方案。但是 CFHTTPAuthentication 的库文档将“kCFHTTPAuthenticationSchemeNegotiate”列为“

以下是来自 attemptToApplyCredentialsAndResume 方法的 ASIHTTPRequest.m 代码的相关部分。

我对协商方案本身也有些困惑。据我了解，如果可能，它应该尝试使用 Kerberos 方案，如果没有，则回退到 NTLM 方案。iOS 支持 NTLM 方案，但这种回退似乎没有发生，至少不是 CFHTTPAuthenticationCreateFromResponse 处理它的方式。

我正在尝试将 Curl 与 SPNEGO 一起使用，通过 ruby​​ 协商一种身份验证。

我尝试了几个库，但似乎 httpi 有办法通过它的路边适配器来做到这一点，就像这个链接：

https://gist.github.com/3179054#comments

我想知道是否有办法将 JSON 数据作为 curl 的“数据”部分而不是链接中给出的文件发送。（我的意思是 curl -d 选项）

我的卷曲是这样的：

curl -X POST -d "{"id": "12341234","fieldsRequested":["title","state","component"]}" -H >"Accept: application/json" -H "Content-类型：application/json" --negotiate -u : >https://abcd.com/find/it

为了在 Windows 上使用 Java 进行客户端 HTTP SPNEGO 身份验证，您需要设置 Windows 注册表项allowtgtsessionkey。这是有据可查的。我不明白的是人们如何解决这个问题？大多数公司网站永远不会接受为了单个软件而在 Windows 中更改此注册表项。如果需要在组织中的每个工作站上进行更改，还要考虑一下麻烦。但这只是理论，因为到目前为止我无法说服我们的任何客户更改此注册表项。

我不怪他们。大多数公司管理员会认为这是一种放松安全措施，因此会反对。

我读过这篇文章： Java 或命令行实用程序中是否有办法使用本机 SSPI API 获取服务的 Kerberos 票证？

但它现在已经很旧了。

所以我真的，真的不明白人们如何让 Windows + Java 客户端 + Kerberos 在大学环境、家庭用户等之外的任何地方工作。

我从企业管理员那里得到的问题是“当 IE 和 Firefox 等应用程序在不设置此键的情况下执行 SPNEGO没有问题时，为什么我们需要设置此注册表键？”。嗯，我知道答案是什么。这是因为（很可能）IE 和 Firefox 等应用程序基于 Windows 原生 GSS API (SSPI)，而 Sun 的 Java 使用自己的实现。

我假设使用类似WAFFLE的东西可以解决问题，但我更喜欢纯 Java 解决方案。我还假设使用基于 Java 的解决方案（例如 Spring security 或 Apache HttpClient）将无济于事，因为它们都会遇到这个问题。

任何帮助或指示将不胜感激。

更新1：

我发现在 Oracle 的错误数据库中有一个RFE。Oracle 员工也提交了一个补丁，并在 JDK 邮件列表中讨论了这个特性。除了据我所知，这在当前的 Java 7 中是不可用的，甚至不是实验性的，这并没有让我变得更聪明。正确的？

更新2：

这个问题现在在 OpenJDK 安全开发邮件列表中再次出现。

我想通过 winrm 连接到其他计算机。我只得到了我想连接的目标计算机的 FQDN。我不知道目的地是否在受信任的域中。所以基本问题是我现在如何连接需要哪种身份验证机制？是否有任何 C# .NET 方法来检查？

或者是将身份验证机制设置为 kerberos 的更简单方法，如果失败则将其设置为协商？

你能用一句话解释下面的Request Header要求什么吗？（这样我就可以找到每个术语的解释：Negotiate、Basic-realm、NTLM）

WWW-Authenticate Negotiate NTLM Basic realm="localhost"

谢谢

我正在尝试在我们目前正在处理的项目中使用 SignalR 库。我已经阅读了一些博客，查看了一些 stackoverflow 答案并检查了 signalr 的文档，但没有任何运气。下面的代码只是我试图使其工作的最简单的示例。

我正在使用带有集线器的 SignalR 1.0.1、jquery 2.0.0、ASP.NET MVC2、.NET Framework 4，信号器/集线器通过Url.Content("~/signalr/hubs"). 在页面的源代码中，当我单击 signalr/hubs 时，我可以看到 SignalR 生成的 js 代码。

我还在RouteTable.Routes.MapHubs();Application_Start() My Hub 的开头添加了：

jQuery 文档就绪块中的客户端代码

问题是： http://localhost/EC/signalr/negotiate返回状态200 OK，但是响应体是空的，所以没有创建连接。

我尝试设置runAllManagedModulesForAllRequests="true"，但没有改变任何东西，也尝试过$.connection.hub.url = 'http://localhost/EC/signalr';但再次没有效果。

我还将我的 hubs 类保存在 Hubs 文件夹或项目的根目录中。

我将不胜感激任何帮助，因为我没有想法，如何以及在哪里寻找解决方案。

我的计算机（Windows，JDK7 更新 21 x64），例如 mybox.domain2.company.com，连接到我公司的域。我可以通过三个不同的网址访问网站：

或者

或者

通过在 IE、Firefox 等中协商身份验证。这里 domain1.company.com 和 domain2.company.com 是我公司的两个域。该站点位于 IIS 7 中，其身份验证为“协商”。

在谷歌搜索和配置 kerberos 之后，我可以在 java 中使用 URLConnection 来访问

. 但是，我可以在浏览器中使用 IP 或主机别名来做到这一点，但在 Java 中却不行。任何人都可以实现直接 IP 访问或主机别名访问吗？

krb5.conf：

登录.conf：

（请注意，所有主机名都只是给出了示例。）

这是一个我认为 RFC 对此保持沉默的问题：https ://www.rfc-editor.org/rfc/rfc5246

当 SSL 连接建立，客户端和服务器之间正在交换应用程序消息时，如果在某个时间触发了重新协商，那么在双方仍在协商时发送的那些应用程序消息会发生什么..？他们被丢弃了吗？它们会导致重新谈判失败吗？

谢谢 ！

我正在开发一个需要使用协商通过代理进行身份验证的应用程序。用户可能没有安装 Kerberos 客户端。我正在尝试使用 MIT Kerberos 库来实现这一点，以避免平台依赖性。我已经使用 krb5_get_init_creds_password 成功获得了 TKT 并验证了它 krb5_verify_init_creds。现在我想创建 SPNEGO 令牌以使用此 TKT 在 HTTP 标头中发送。谁能告诉我创建 SPNEGO 令牌的任何 API 或方法？

一些客户端需要能够使用基本身份验证连接到我们的 WCF SOAP 服务，而其他客户端需要使用 Windows 身份验证。我们通常在 IIS 中托管我们的服务，尽管我们确实提供了一个不太发达的 Windows 服务托管选项。

据我了解，不可能将一个端点配置为同时支持基本身份验证和 Windows 身份验证。所以我们每个服务有两个端点。

它们位于 IIS 中的同一个 Web 应用程序中。该 Web 应用程序同时启用了基本和 Windows 身份验证（否则上述绑定之一将不起作用）。

当客户端使用 Windows 身份验证的端点（在 URL 的末尾带有“win”）时，这通常可以正常工作。当初始请求不包含任何身份验证信息时，客户端和 IIS 之间会进行协商，他们选择 Windows 身份验证，一切顺利。

当客户端使用经过基本身份验证的端点（URL 末尾没有“win”）时，如果它们包含 Authorization HTTP 标头以及其中的正确编码凭据，则此方法有效。但是，如果它们在初始请求中不包含任何身份验证信息，则协商最终会选择 Windows 身份验证。这使请求通过了 IIS 安全性，但 WCF 随后拒绝了该请求，因为它会发送到经过基本身份验证的终结点。

我对谈判中到底发生了什么感到很模糊。但在我看来，IIS 提供了为 Web 应用程序启用的所有身份验证方法（即 Basic 和 Windows），即使请求的特定 WCF 端点 URL 仅支持 Basic。

我想知道我们是否可以在 IIS 中做任何事情来使协商得出正确的答案：也就是说，如果请求是针对 Basic 身份验证的端点，请告诉客户端使用 Basic。当然，当请求到达 Windows 身份验证的端点时，我们仍然希望协商最终选择 Windows。

如果没有，那么您认为我们是否会更好地专注于我们的 Windows 服务托管版本的服务？还是会以某种方式有类似的问题？

最后一点：我们确实将 Basic 与 HTTP 一起用于一些内部用途，但我们知道这是一个不安全的组合。所以我们通常会打开 HTTPS 用于生产用途；为了简单起见，我把它留在这里了。