【问题标题】:Configure ASP.NET Core Module to host on https instead of http for IdentityServer 4将 ASP.NET Core 模块配置为在 https 而不是 http 上托管 IdentityServer 4
【发布时间】:2017-06-26 16:56:05
【问题描述】:

我遇到的问题是当我尝试在使用 SSL 的 IIS 服务器上托管 IdentityServer4 的实现时。 (完全 SSL 严格)

在激活 SSL 的情况下单独在 Kestrel 上运行我的应用程序时,它可以正常工作,并且 IdentityServer 的 IssuerUriDiscovery Endpoints 使用 SSL 绑定。但是,当我将它托管在 ASP.NET Core 模块后面时,它会将其托管在 http://localhost:{random port} 上,这反过来又会为非 https 的 Identityserver 生成 IssuerUriEndpoints

我尝试了以下方法但没有成功:

  1. 确保我在 IIS 网站上有一个有效的证书 端口 80 上的 https 绑定和删除绑定

  2. 尝试在 web.config 中更改环境变量 ASPNETCORE_URLS 指向一个 https 地址。

  3. 尝试在 web.config 中重写和重定向规则。

  4. IISOptions 上查找设置(由.UseIISIntegration() 使用) 在我的启动类中绑定到特定的 url 或更改协议。

  5. 试图找到类似的设置,如 RequireSSL (IdentityServer 3) 或 RequireHttpsMetadata 在 IdentityServer4 中。

  6. 在启动类的 IdentityServer 选项中更改了 IssuerUri 希望它也可以更新其他端点。

我可能错过了一些非常明显的东西,但现在我不知道那可能是什么。

非常感谢社区提供的任何帮助 :-)

Program.cs 代码

    public static void Main(string[] args)
    {
        Console.Title = "IdentityServer";

        var config = new ConfigurationBuilder()
            .SetBasePath(Directory.GetCurrentDirectory())
            .AddJsonFile("kestrelHosting.json", optional: true)
            .AddCommandLine(args)
            .Build();

        var host = new WebHostBuilder()
            .UseConfiguration(config)
            .UseKestrel(options =>
            {
                // options.ThreadCount = 4;
                options.NoDelay = true;
                options.UseHttps("VismaCert.pfx", "Visma123");
                //options.UseConnectionLogging();
            })
            .UseContentRoot(Directory.GetCurrentDirectory())
            .UseIISIntegration()
            .UseStartup<Startup>()
            .Build();

        host.Run();
    }

【问题讨论】:

    标签: iis asp.net-core identityserver4


    【解决方案1】:

    AspNetCoreModule 是 SSL 终结器,它不会通过 HTTPS 与 Kestrel 通信。它所做的是通过标头转发原始方案,以便您可以在生成 url/链接时使用它。 UseIISIntegration 默认包含一个 ForwardedHeaders 中间件,它将获取这些标头并将它们应用于请求字段。但是,在某些情况下,默认设置无法处理标头。这里有一堆参考资料:https://github.com/aspnet/Docs/issues/2384

    【讨论】:

    • 感谢@Tratcher 的回复。按照您的链接并在 ARR 中添加响应标头后,我现在得到以下信息。 “X-FORWARDED-HOST:xxxxxxxx.xxx.xxx”、“X-FORWARDED-SCHEMA:https”、“X-FORWARDED-PROTO:https、http”和“X-Forwarded-For:xx.xx.x.xx :xxxxxx”。不幸的是,identityserver 似乎没有接受这些更改,而是读取 HttpContext.Request.Schema 而不是检查是否已为其 BaseUrlMiddleware 设置了值为 https 的 Request.Header["X-Forwarded-Proto"],所以我将向他们提出一个关于如何最好地进行的新问题。
    • 在转发标头选项中禁用要求标头对称。您的 proto 和 For 具有不同数量的值。
    • 嗨,是的,我想知道如果两者都存在,中间件将如何确定要使用的协议。就像现在一样,我在代码中设置了这个,但我仍然得到双倍值,也没有在 https 上使用。 app.UseForwardedHeaders(new ForwardedHeadersOptions { ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto, ForwardLimit = null, RequireHeaderSymmetry = false }); 如果我的设置正确,那么 HttpContext.Request.Schema 会将其值设置为 https 而不是 http?
    • 是的,如果您获得正确的设置,那么 Request.Scheme 将是 https。试试 ForwardLimit = 2
    • 我尝试按照您的建议设置ForwardLimit = 2,但它仍然只将Request.Schema设置为http。我仍然将“https”和“http”作为X-Forwarded-Proto 标头中的设置值。我可以让它工作的唯一方法是在代码context.Request.Scheme = "https"; 中手动设置它。如果我应该将其设置为 https 或不通过 appsetting 进行管理,但我认为如果我能让它工作的话,在转发的 proto 标头上获取它的方式是一种更好的方法。
    猜你喜欢
    • 2018-02-12
    • 2021-02-04
    • 1970-01-01
    • 2010-11-10
    • 1970-01-01
    • 2018-03-02
    • 1970-01-01
    相关资源
    最近更新 更多