Взаимная аутентификация в приложении Cloud Foundry с NodeJS + express

Question

Я разработал приложение NodeJs + express , развернутое как Приложение Cloud Foundry в IBM Cloud. Я хочу выполнить взаимную аутентификацию (сертификаты клиента и сервера), чтобы контролировать входящий трафик и запросы к моему приложению. Мои сертификаты генерируются Secure Gateway , как описано здесь , с моим приложением, настроенным как облачное целевое устройство (доступное из локальных клиентов).

Secure Gateway сгенерировал следующие файлы pem: первичный, промежуточный и корневой сертификат сервера и целевой сертификат и ключ. В документации приведен довольно ясный пример Nodejs с использованием tls.createServer.

В моем сценарии есть некоторые различия: Прежде всего, я нахожусь в противоположном сценарии (когда локальные клиенты подключаются к облачному приложению через Secure Gateway, создавая туннель). Во-вторых, и это главная причина этого поста, мое приложение развернуто как приложение CF.

Чтение документации CF по HTTP-маршрутизации Я выяснил, что облако IBM использует только порты 80 и 443, а затем перенаправляет запросы через HTTP на порты, которые слушает приложение (например, если мои NodeJ работают на порту 6001, и я вызываю оконечную точку облака на порту 443, GoRouter перенаправит запрос через HTTP на правильный порт, добавив заголовок X-Forwarded-Proto, чтобы передать приложению информацию об исходном протоколе, используемом для запроса.

Имея это в виду (предполагая, что это правильно), в своем коде NodeJ я не могу использовать что-то вроде https.createServer(opts, app), учитывая, что все запросы, поступающие в Контейнер приложений, будут через HTTP.

Чтение документов CF здесь Я понимаю, что можно сказать CF о пересылке сертификатов до моего приложения, но есть кое-что, что я не могу по-настоящему понять.

Прежде всего, в чем разница между завершением TLS на балансировщике нагрузки или на GoRouter? Каковы причины этого выбора?

Мой второй вопрос: как правильно обрабатывать сертификаты после их отправки в мое приложение как заголовки HTTP? Это связано с тем, что мой сервер NodeJs будет http-сервером, созданным с помощью express стандартным способом http.createServer(app).

Спасибо всем, кто поможет мне разобраться в этом. Очевидно, что если у вас есть примеры или советы, это было бы очень полезно.

Answer 1

Чтение документации CF по маршрутизации HTTP Я выяснил, что облако IBM использует только порты 80 и 443, а затем перенаправляет запросы через HTTP на порты, которые слушает приложение (например, если мои NodeJ работают на порту 6001и я вызываю конечную точку облака на порту 443, GoRouter перенаправит запрос через HTTP на правильный порт, добавив заголовок X-Forwarded-Proto для передачи приложению информации об исходном протоколе, используемом для запроса.

Имея это в виду (предполагая, что это правильно), в моем коде NodeJs я не могу использовать что-то вроде https.createServer (opts, app), давая, что все запросы, поступающие в контейнер приложений, будут через HTTP.

Это правильно.

Прежде всего, в чем разница между завершением TLS на балансировщике нагрузки или на GoRouter? Каковы причины такого выбора?

Это применимо только в том случае, если вы работаете на собственной платформе Cloud Foundry. Если вы развертываете приложения на Cloud Платформа литейного производства управляется кем-то другим, и они примут это решение, и оно не повлияет на вас как на пользователя.

Как оператор, это выбор, который вам нужно сделать.Есть некоторые компромиссы в зависимости от того, что вы решите делать.

1. Вы можете завершить на LB.Обычно это самый быстрый способ, так как LB очень эффективны в обработке TLS / SSL.Затем LB может пересылать трафик на Gorouter в незашифрованном виде, что требует меньше работы на Gorouter, но происходит за счет того, что трафик не шифруется между ними (может быть не в порядке, в зависимости от требований безопасности).В этом случае ответственность за добавление заголовков x-forwarded-* несет LB.

   browser -> HTTPS -> LB -> HTTP -> Gorouters -> HTTP -> Ваше приложение

2. Вы можете использовать LB уровня 4 и сбалансировать соединения между вашими Gorouters.Это позволяет Gorouters завершать TLS / SSL.Они довольно эффективны в этом, но менее, чем большинство LB.Это также дает вам шифрование в пути запроса до Gorouter.В этом сценарии Gorouters отвечает за добавление заголовков x-forwarded-*.

   browser -> HTTPS -> LB -> HTTPS -> Gorouters -> HTTP -> Ваше приложение

3. Вы можете завершить сеанс на LB, но открыть новый сеанс TLS / SSL между LB и Gorouters.Это наименее эффективный вариант, поскольку он требует завершения двух сеансов TLS / SSL, но он обеспечивает шифрование в пути запроса до Gorouter.Он также, как правило, наиболее гибок в работе с LB не уровня 4 и может позволить вашему LB проверять трафик HTTP, поскольку вы завершаете сеанс на LB.В этом сценарии LB обязан добавить заголовки x-forwarded-*.

   browser -> HTTPS (сеанс A) -> LB -> HTTPS (сеанс B) -> Gorouters -> HTTP -> Ваше приложение

Опять же, если вы не используете платформу Cloud Foundry, вы можете проигнорировать это.

Мой второй вопрос:правильный способ обработки сертификатов после их отправки в мое приложение как заголовки HTTP?Это связано с тем, что мой сервер NodeJs будет http-сервером, созданным с помощью express стандартным способом http.createServer (app).

Вам не нужно ничего делать сспособ создания вашего сервера.Все, что вам нужно сделать, это посмотреть на x-forwarded-* заголовки и использовать их для принятия ваших решений.

1. Пришел ли запрос по HTTPS? Посмотрите либоx-forwarded-proto, который должен быть установлен на https для запросов HTTPS или посмотрите на x-forwarded-port, который должен быть установлен на 443 для запросов HTTPS.

2. Былклиентский сертификат, предоставленный с запросом? Посмотрите на X-Forwarded-Client-Cert.Если он содержит сертификат, то клиент предоставил сертификат.

3. Сертификат клиента действителен? Если ваше приложение получает запрос, сертификат клиента действителен.Вы знаете это, потому что платформа обрабатывает эту часть для вас.Поскольку платформа (либо LB, либо Gorouter) завершает соединение TLS / SSL, она несет ответственность за проверку сертификата.Если ваше приложение получает запрос & x-forwarded-client-cert установлено, то сертификат действителен.

4. Как принимать решения об авторизации на основе сертификата клиента? Этоэто немного сложнее, но обычно вы извлекаете сертификат из x-forwarded-client-cert, читаете / анализируете его и принимаете решения на основе содержимого сертификата (что, как мы знаем, является действительным благодаря платформе).Скорее всего, вы будете смотреть на имя субъекта и относиться к нему как к имени пользователя.Затем найдите роли или разрешения для этого пользователя.Однако, как вы справляетесь с этим, зависит от вас, как от разработчика.

Надеюсь, это поможет!