Настройте модуль ASP.NET Core для размещения на https вместо http для IdentityServer 4

У меня возникает проблема, когда я пытаюсь разместить реализацию IdentityServer4 на сервере IIS, который использует SSL. (Полный SSL строгий)

При запуске моего приложения только на Kestrel с активированным SSL оно работает нормально, а IssuerUri и Discovery Endpoints для IdentityServer используют привязку SSL. Однако, когда я размещаю его за модулем ASP.NET Core, он размещает его на http://localhost:{random port}, который, в свою очередь, генерирует IssuerUri и Endpoints для Identityserver, которые не являются https.

Я безуспешно пробовал следующее:

  1. Убедился, что у меня есть действующий сертификат на веб-сайте IIS для привязки https, и удалил привязку к порту 80.

  2. Пытался изменить переменную среды ASPNETCORE_URLS в web.config, чтобы она указывала на адрес https.

  3. Пробовал переписывать и перенаправлять правила в web.config.

  4. Искал настройки на IISOptions (используется .UseIISIntegration()) в моем классе запуска для привязки к определенному URL-адресу или изменения протокола.

  5. Пытался найти похожие настройки типа RequireSSL (IdentityServer 3) или RequireHttpsMetadata в IdentityServer4.

  6. Изменил IssuerUri в параметрах IdentityServer в классе запуска, надеясь, что он также может обновить другие конечные точки.

Я, вероятно, пропустил что-то очень очевидное, но сейчас я не имею ни малейшего представления о том, что это могло быть.

Любая помощь от сообщества будет принята с благодарностью :-)

Код 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();
    }

person Peter Städe    schedule 08.02.2017    source источник


Ответы (1)


AspNetCoreModule - это терминатор SSL, он не будет связываться с Kestrel по HTTPS. Что он делает, так это пересылает исходную схему через заголовок, чтобы вы могли использовать ее при создании URL-адресов / ссылок. По умолчанию в UseIISIntegration входит промежуточное ПО ForwardedHeaders, которое принимает эти заголовки и применяет их к полям запроса. Однако бывают ситуации, когда заголовки не могут быть обработаны по умолчанию. Здесь есть несколько ссылок: https://github.com/aspnet/Docs/issues/2384

person Tratcher    schedule 09.02.2017
comment
Спасибо @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 вместо того, чтобы проверять, установлен ли Request.Header [X-Forwarded-Proto] со значением https для него BaseUrlMiddleware, поэтому я обратится к ним с новым вопросом о том, как лучше всего действовать. - person Peter Städe; 11.02.2017
comment
В параметрах перенаправленных заголовков отключено требование симметрии заголовков. Ваши proto и For имеют разное количество значений. - person Tratcher; 12.02.2017
comment
Привет, да. Я сам задавался вопросом, как промежуточное ПО сможет определить, какой протокол использовать, если бы оба присутствовали. На данный момент у меня есть этот набор в коде, но я все еще получаю двойные значения, а также не собираю https. app.UseForwardedHeaders(new ForwardedHeadersOptions { ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto, ForwardLimit = null, RequireHeaderSymmetry = false }); Если бы у меня все было правильно настроено, HttpContext.Request.Schema заменил бы его значение, установленное на https вместо http? - person Peter Städe; 13.02.2017
comment
Да, при правильных настройках Request.Scheme будет https. Попробуйте ForwardLimit = 2 - person Tratcher; 14.02.2017
comment
Я пробовал, как вы предлагали, установить ForwardLimit = 2, но он все еще устанавливает Request.Schema как http. У меня по-прежнему есть и https, и http в качестве установленных значений в заголовке X-Forwarded-Proto. Единственный способ заставить его работать - это установить его вручную в коде context.Request.Scheme = "https";. Если я должен установить для него https или нет, это регулируется через приложение, но я думаю, что способ получения его в перенаправленном заголовке прото - лучший подход, если бы я мог заставить его работать. - person Peter Städe; 14.02.2017