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

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

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

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

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

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

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

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

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

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

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

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

   браузер -> 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, читаете / анализируете его и принимаете решения на основе содержимого сертификата ( который, как мы знаем, действителен благодаря платформе). Скорее всего, вы собираетесь смотреть на имя субъекта и относиться к нему как к имени пользователя. Затем найдите роли или разрешения для этого пользователя. Однако то, как вы с этим справитесь, зависит от вас как разработчика.

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