问题描述
我使用Visual Studio 2015年企业和ASP.NET vNext Beta8构建在细节here.由于这篇文章端点使用AspNet.Security.OpenIdConnect.Server（AKA OIDC）中的说明做繁重。
I am using Visual Studio 2015 Enterprise and ASP.NET vNext Beta8 to build an endpoint that both issues and consumes JWT tokens as described in detail here. As explained in that article the endpoint uses AspNet.Security.OpenIdConnect.Server (AKA OIDC) to do the heavy lifting.
而站在这个原型起来我们内部的开发环境，我们遇到了使用它与负载均衡的问题。特别是，我们认为这与上app.UseJwtBearerAuthentication了机构的设置，我们的HTTP / HTTPS的奇特混合做。随着我们的负载平衡的环境中，任何试图调用使用该令牌的REST方法产生此异常：
While standing this prototype up in our internal development environment we have encountered a problem using it with a load balancer. In particular, we think it has to do with the "Authority" setting on app.UseJwtBearerAuthentication and our peculiar mix of http/https. With our load balanced environment, any attempt to call a REST method using the token yields this exception:
引发WebException：远程名称无法解析：devapi.contoso.com.well知名
HTT prequestException：发送请求时发生错误
。
IOException异常：IDX10804：无法检索文件：。
考虑以下步骤重现（这是为原型，不应该被认为是值得的生产）：
Consider the following steps to reproduce (this is for prototyping and should not be considered production worthy):
-
我们创建使用OIDC一个beta8原型描述here.
我们部署该项目以2相同配置IIS服务器2012 R2上运行的服务器8.5。在IIS服务器主机称为API与绑定端口80和443的主机名devapi.contoso.com（消毒这个职位的目的）上的所有可用IP地址的beta8网站。
We deployed the project to 2 identically configured IIS 8.5 servers running on Server 2012 R2. The IIS servers host a beta8 site called "API" with bindings to port 80 and 443 for the host name "devapi.contoso.com" (sanitized for purposes of this post) on all available IP addresses.
这两个IIS服务器有一个主机条目指向自己：
Both IIS servers have a host entry that point to themselves:
127.0.0.1 devapi.contoso.com
127.0.0.1 devapi.contoso.com
我们的网络管理员已经绑定一个*证书（为* .contoso.com）与我们坎普负载均衡和配置的来解决负载平衡器。
Our network admin has bound a * certificate (*.contoso.com) with our Kemp load balancer and configured the DNS entry for https://devapi.contoso.com to resolve to the load balancer.
现在这是很重要的，负载均衡器也已经使用配置为代理HTTPS流量到IIS服务器上的 HTTP （不的，重复的不的上HTTPS）。它已经向我解释，这是我们公司的标准作业程序，因为他们只需要安装该证书在一个地方。 我们不知道为什么我们的网络管理员在IIS中的约束443，因为它在理论上从来没有收到这个端口上的任何流量。的
Now this is important, the load balancer has also been configured to proxy https traffic to the IIS servers using http (not, repeat, not on https). It has been explained to me that this is standard operating procedure for our company because they only have to install the certificate in one place. We're not sure why our network admin bound 443 in IIS since it, in theory, never receives any traffic on this port.
我们做出通过HTTPS安全岗位获取一个令牌，该令牌工作正常（如何使这个职位的细节是here ）：
We make a secure post via https to https://devapi.contoso.com/authorize/v1 to fetch a token, which works fine (the details of how to make this post are here ):
{
子：待办事项，
ISS：，
AUD：，
EXP：1446158373，
NBF：1446154773
}
{
"sub": "todo",
"iss": "https://devapi.contoso.com/",
"aud": "https://devapi.contoso.com/",
"exp": 1446158373,
"nbf": 1446154773
}
我们再使用此令牌在另一个安全的GET通过HTTPS 。
We then use this token in another secure get via https to https://devapi.contoso.com/values/v1/5.
OpenIdConnect.OpenIdConnectConfigurationRetriever抛出异常：
OpenIdConnect.OpenIdConnectConfigurationRetriever throws the exception:
引发WebException：远程名称无法解析：devapi.contoso.com.well知名
HTT prequestException：发送请求时发生错误
。
IOException异常：IDX10804：无法检索文件：。
我们认为这发生，因为OIDC正试图协商，options.Authority指定的主机，这是我们设置在启动时的。再者，我们推测，因为我们的环境已经被配置以转换HTTPS流量的负载均衡和IIS的东西之间的非HTTPS流量脚麻当框架试图解决的。我们已经尝试了许多配置更改甚至包括指向权力非安全以没有结果。
We think this is happening because OIDC is attempting to consult the host specified in "options.Authority", which we set at startup time to https://devapi.contoso.com/. Further we speculate that because our environment has been configured to translate https traffic to non https traffic between the load balancer and IIS something is going wrong when the framework tries to resolve https://devapi.contoso.com/. We have tried many configuration changes including even pointing the authority to non-secure http://devapi.contoso.com to no avail.
在帮助我们理解这个问题将大大AP preciated任何帮助。
Any assistance in helping us understand this problem would be greatly appreciated.
推荐答案
@Pinpoint是正确的。此异常是由OIDC配置code路径，允许IdentityModel启动非HTTPS调用引起的。特别是我们正在使用code样品在权力缺少URI拖尾斜杠敏感。下面是使用URI类路径，以可靠的方式相结合，无论管理局URI是否有尾随斜线的code片段：
@Pinpoint was right. This exception was caused by the OIDC configuration code path that allows IdentityModel to initiate non-HTTPS calls. In particular the code sample we were using was sensitive to missing trailing slash in the authority URI. Here is a code fragment that uses the Uri class to combine paths in a reliable way, regardless of whether the Authority URI has a trailing slash:
public void Configure(IApplicationBuilder app, IOptions<AppSettings> appSettings)
{
.
.
.
// Add a new middleware validating access tokens issued by the OIDC server.
app.UseJwtBearerAuthentication
(
options =>
{
options.AuthenticationScheme = JwtBearerDefaults.AuthenticationScheme ;
options.AutomaticAuthentication = false ;
options.Authority = new Uri(appSettings.Value.AuthAuthority).ToString() ;
options.Audience = new Uri(appSettings.Value.AuthAuthority).ToString() ;
// Allow IdentityModel to use HTTP
options.ConfigurationManager =
new ConfigurationManager<OpenIdConnectConfiguration>
(
metadataAddress : new Uri(new Uri(options.Authority), ".well-known/openid-configuration").ToString(),
configRetriever : new OpenIdConnectConfigurationRetriever() ,
docRetriever : new HttpDocumentRetriever { RequireHttps = false }
);
}
);
.
.
.
}
在本例中，我们管理局URI从config.json通过appSettings.Value.AuthAuthority揪，然后消毒/使用的类。
In this example we're pulling in the Authority URI from config.json via "appSettings.Value.AuthAuthority" and then sanitizing/combining it using the Uri class.
这篇关于AspNet.Security.OpenIdConnect.Server（ASP.NET vNext）机构配置混合HTTP / HTTPS环境的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！