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

Reading CF documentation about HTTP routing I figured out that IBM cloud only uses ports 80 and 443 and then forwards the requests via HTTP to the ports the app is listening to (for example if my NodeJs is running on port 6001 and I call the cloud endpoint on port 443, the GoRouter will forward the request via HTTP to the correct port, adding the X-Forwarded-Proto header to pass the application the information of the original protocol used for the request.

Having this in mind (assuming this is correct), in my NodeJs code I cannot use something like https.createServer(opts, app) giving that all the requests coming to the App Container will be via HTTP.

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

First of all what is the difference between terminating TLS at Load Balancer or at GoRouter? What are the reasons behind this choice?

Это применимо только в том случае, если вы используете собственную платформу 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, вы можете игнорировать это.

My second question is which is the correct way of handling the certificates once they are forwarded to my application as HTTP headers? This is due to the fact the my NodeJs server will be an http server, created with express in the standard way 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, читаете / анализируете его и принимаете решения на основе содержимого сертификата (которое, как мы знаем, является действительным благодаря платформе). Скорее всего, вы будете смотреть на имя субъекта и относиться к нему как к имени пользователя. Затем найдите роли или разрешения для этого пользователя. Однако то, как вы с этим справитесь, зависит от вас как разработчика.

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