AspNet.Security.OpenIdConnect.Server (ASP.NET vNext) authorization configuration in mixed HTTP / https

I use Visual Studio 2015 Enterprise and ASP.NET vNext Beta8 to create an endpoint that has both problems and consumes JWT tokens, as described in detail here . As explained in this article, the endpoint uses AspNet.Security.OpenIdConnect.Server (AKA OIDC) to do the hard work.

Despite the fact that this prototype is in our internal development environment, we are faced with a problem using it with a load balancer. In particular, we think this is due to the Power setting on app.UseJwtBearerAuthentication and our unique combination of http / https. With our load-balanced environment, any attempt to call the REST method using a token gives this exception:

WebException: remote name could not be resolved: 'devapi.contoso.com.well-known' HttpRequestException: An error occurred while sending the request.
IOException: IDX10804: Unable to get document from: ' https: //devapi.contoso.com.well-known/openid-configuration '.


Consider the following steps for reproduction (this is for prototyping and should not be considered worthy of production):

  • We created a beta8 prototype using OIDC as described here .

  • We deployed a project for 2 identically configured IIS 8.5 servers running on 2012 R2 server. IIS servers host a beta-8 site called "API" with bindings to ports 80 and 443 for the hostname "devapi.contoso.com" (sanitized for the purpose of this message) at all available IP addresses.

  • Both IIS servers have a host entry that points to themselves:

    127.0.0.1 devapi.contoso.com

  • Our network administrator associated the * certificate (* .contoso.com) with our Kemp load balancer and set up a DNS record for https://devapi.contoso.com to enable load balancing.

  • Now this is important, the load balancer is also configured to proxy https traffic to IIS servers using http (not, repeat, not https). They explained to me that this is a standard operating procedure for our company, because they only need to install the certificate in one place. We do not know why our network administrator bound 443 in IIS, since theoretically he never receives any traffic on this port.

  • We make a secure post via https for https://devapi.contoso.com/authorize/v1 in order to get a token that works fine (details on how to make this post here ):

    {
    "sub": "todo",
    "iss": " https://devapi.contoso.com/ ",
    "aud": " https://devapi.contoso.com/ ",
    "exp": 1446158373,
    "nbf": 1446154773
    }

  • Then we use this token in another secure get via https for https://devapi.contoso.com/values/v1/5 .

  • OpenIdConnect.OpenIdConnectConfigurationRetriever throws an exception:

WebException: remote name could not be resolved: 'devapi.contoso.com.well-known' HttpRequestException: An error occurred while sending the request.
IOException: IDX10804: Unable to get document from: ' https: //devapi.contoso.com.well-known/openid-configuration '.


We think this is happening because the OIDC is trying to consult the host specified in "options.Authority", which we set during the start of https://devapi.contoso.com/ . Further, we assume that since our environment was configured to translate https traffic to https traffic between the load balancer and IIS, something happens incorrectly when the environment tries to resolve https://devapi.contoso.com/ . We tried many configuration changes, including even specifying permissions on the insecure http://devapi.contoso.com to no avail.

Any help helping us understand this problem would be greatly appreciated.

+2
jwt openid-connect
Oct 29 '15 at 23:02
source share
1 answer

@Pinpoint was right. This exception was caused by the OIDC configuration code code, which allows the IdentityModel to initiate calls without HTTPS. In particular, the code sample we used was sensitive to the absence of a trailing slash in the authorization URI. Here's a snippet of code that uses the Uri class for a reliable combination of paths, regardless of whether the 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 } ); } ); . . . } 

In this example, we pull the authorization URI from config.json through "appSettings.Value.AuthAuthority" and then sanitize / merge it using the Uri .

+1
Oct 30 '15 at 15:27
source



All Articles