Преобразование Mutal TLS в OAuth ClientCredentials с помощью Ngnix, Apache, Envoy или другого обратного прокси

Question

У меня есть ряд сервисов, которые аутентифицируются с помощью токенов OAuth Bearer. Я могу получить токены, используя либо грант OAuth Client Credentials, либо Resource Owner Credentials Grant.

Однако у меня есть ряд существующих систем, которые могут выполнять вызовы, аутентифицированные только с использованием соединений Mutual TLS.

Вместо того, чтобы обновлять все вызывающие приложения, чтобы иметь возможность получать токены носителя OAuth, я бы вместо этого хотел создать прокси шлюза, который:

1. Получает соединения с проверкой подлинности TLS
2. Использование субъекта сертификата для идентификации системного субъекта
3. Получение токена от имени этой системы с использованием учетных данных клиента или гранта владельца ресурса
4. Выполните вызов базовой службы и верните результаты клиенту

По сути, я хочу скрыть тот факт, что OAuth используется от старых клиентов, и разрешить им работать исключительно с Mutal TLS Authentication.

Существуют ли обратные прокси-серверы или способы или модули для Ngnix, Apache, Envoy или аналогичных обратных прокси-серверов HTTP, которые могли бы достичь этого без создания полного прокси?

Я обнаружил множество модулей, которые обрабатывают случай настройки Apache и Ngnix в качестве ретранслятора OAuth или сервера ресурсов с использованием различных модулей, таких как

• https://github.com/zmartzone/lua-resty-openidc
• https://findingscience.com/mod_auth_openid/

Но не могу найти примеров того, как они выступают в качестве клиента OAuth или Open ID Connect в качестве прокси-сервера для клиента с проверкой подлинности Mutual TLS.

Особенно я хочу избежать написания прокси-части. Даже если мне нужно написать сценарий реального взаимодействия OAuth. Самое близкое, что я нашел, - это сообщение в блоге о реализации OAuth RP в скриптах Envoy lua .

Мне трудно представить, что это уникальная потребность, поэтому мне интересно, есть ли какая-нибудь стандартная реализация этого шаблона, которую я не нашел.

Answer 1

Оказывается, это легко осуществить с помощью Envoy Proxy.В частности, используя HTTP-фильтры External Authorization .

Прокси-агент Envoy можно настроить для выполнения SSL-завершения и требовать сертификат клиента, установив Нисходящий TLS-контекст .на приемнике и настройке require_client_certificate на true.

Можно настроить Сетевой фильтр диспетчера подключений HTTP для установки заголовка x-forwarded-client-cert в запросе к восходящей службе.В частности, установка forward-client-cert-details в SANITIZE_SET приведет к тому, что посланник установит заголовок.То, что включено в заголовок, можно настроить, установив set-current-client-cert-details .

Но для того, чтобы на самом деле Envoy выполнял обмен токенами, нам нужно настроить фильтр внешней авторизации,Это позволяет посланнику вызывать службу с подробностями запроса (включая сертификат), и эта служба может решить, разрешен ли запрос или нет.Важно отметить, что когда это разрешено, он может добавлять заголовки к запросу, направленному на вышестоящие сервисы, что позволяет ему добавлять токен-носитель, необходимый для oauth.

Существуют версии фильтра внешней авторизации как сетевого фильтра, так и фильтра HTTP.Вы должны использовать HTTP, если хотите добавить заголовки к исходящему запросу.

Получившаяся конфигурация посланника выглядит следующим образом:

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
          stat_prefix: ingress_http
          forward_client_cert_details: SANITIZE_SET # Include details of the client certificate in the x-forwarded-client-cert header when calling the upstream service
          set_current_client_cert_details:
            subject: True # Include the subject of the certificate in the x-forwarded-client-cert header rather than just the certificate hash.
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: service_backend
          http_filters:
          - name: envoy.ext_authz # Call an authorization service to do the OAuth token exchange
            config:
              grpc_service:
                envoy_grpc:
                  cluster_name: auth_service
                timeout: 5s # The timeout before envoy will give up waiting for an auth service response and deny access
          - name: envoy.router
      tls_context:
        require_client_certificate: True # Require downstream callers to provide a client certificate
        common_tls_context:
          validation_context:
            trusted_ca:
              filename: /etc/envoy/certs/ca-chain.cert.pem # CA certificate that client certificate must be signed with to be accepted
          tls_certificates:
          - certificate_chain:
              filename: /etc/envoy/certs/server-cert.pem
            private_key:
              filename: /etc/envoy/certs/server-key.pem
            password:
              inline_string: password
  clusters:
  - name: auth_service
    connect_timeout: 1s # The timeout before envoy will give up trying to make a TCP  connectio to an auth service
    type: LOGICAL_DNS
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    http2_protocol_options: {} # GRPC services must be HTTP/2 so force HTTP/2
    load_assignment:
      cluster_name: auth_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: localhost
                port_value: 8080

Хитрость заключается в реализации службы GRPC, реализующей протокол внешней авторизации для выполнения обмена токенами и отклонения запроса или предоставления заголовка Authorization для включения токена-носителя в запрос восходящего направления.