Запросы REST фабрики службы проверки подлинности
Кластер Service Fabric можно защитить с помощью сертификатов X.509, Kerberos или сочетания сертификатов X.509 и Kerberos. В этой статье рассматриваются следующие вопросы:
Изменение манифеста кластера для получения соответствия HttpGatewayEndpoints (конечной точки REST) конкретному решению безопасности.
Изменение вызовов REST для работы с каждым решением (X.509, Kerberos или X.509 с Kerberos).
Шлюз HTTP с защитой X.509
В Azure и локальной среде конечные точки REST Service Fabric поддерживают использование сертификатов X.509 для:
Проверка подлинности и авторизация клиентов. В зависимости от сертификатов Можно настроить Service Fabric для предоставления доступа пользователям, администраторам или отсутствия доступа к клиенту REST.
Проверка подлинности узлов Service Fabric. Клиенты REST могут проверить, взаимодействуют ли они с одним из правильных узлов Service Fabric.
Шифрование сообщений (запросов и ответов REST).
Примечание
Клиенты с пользовательским доступом имеют разрешение только на выполнение запросов на чтение (например, https://localhost:19007/Nodes?api-version=6.0). Клиенты с административным доступом имеют разрешение на выполнение запросов на чтение и запись (пример запроса на запись: https://localhost:19007/Nodes/<NodeName>/$/Deactivate?api-version=6.0).
Изменения манифеста кластера
В этом разделе предполагается, что у вас уже есть манифест кластера, настроенный для использования сертификатов X.509. Дополнительные сведения см. в статье Защита кластера с помощью сертификатов X.509.
Чтобы настроить кластер для поддержки проверки подлинности и авторизации клиентов (пользователей и Администратор) и проверки подлинности узлов Service Fabric, в манифесте кластера необходимо задать следующие параметры:
Отпечаток сертификатов сервера и клиента для каждого типа узла:
<ClientCertificate X509FindValue="…" />
<ServerCertificate X509FindValue="…" />
Раздел безопасности:
<Parameter Name="ClientRoleEnabled" Value="true" />
<Parameter Name="ServerAuthCredentialType" Value="X509" />
Параметр ClientAuthAllowedCommonNames
Параметр AdminAllowedCommonNames
Параметр ServerAuthAllowedCommonNames
Чтобы включить HttpGateway в манифесте кластера, который уже защищен с помощью X.509 (то есть безопасность кластера и клиента или сервера уже включена), требуются только следующие изменения:
Установите https в качестве значения протокола для всех элементов HttpGatewayEndpoint. Например, <HttpGatewayEndpoint Port="19017" Protocol="https"/>
Включите HttpGateway в разделе HttpGateway. Например, <Parameter Name="IsEnabled" Value="true"/>
Использование REST API с X.509
Для защищенного с помощью X.509 HTTPS-запроса создайте соответствующий сертификат клиента (общее имя которого задается в параметре ClientAuthAllowedCommonNames или AdminAllowedCommonNames) и отпечаток сертификата сервера.
Для защищенной с помощью X.509 конечной точки HTTP REST API не изменяются. URL-адреса, заголовки HTTP, запросы и тела ответа вызова REST останутся без изменений.
Шлюз HTTP с защитой Kerberos (или NTLM)
Локальные кластеры Service Fabric могут использовать Kerberos и NTLM для проверки подлинности и авторизации клиентов пользователей и администраторов, а также проверки подлинности серверов (узлов Service Fabric). Однако с помощью Kerberos или NTLM нельзя шифровать сообщения.
Примечание
Рекомендуется использовать протокол HTTPS и проверять, что манифест кластера включает сертификаты сервера при использовании Kerberos.
Корпорация Майкрософт рекомендует пользователям, применяющим защиту Kerberos, также использовать протокол HTTPS. Это означает, что кластер должен иметь сертификаты X.509 сервера. Таким образом сертификаты сервера будут использоваться для шифрования взаимодействия.
Основное преимущество использования проверки подлинности Kerberos вместо сертификатов X.509 для клиентов заключается в том, что Kerberos упрощает управление сертификатами клиента.
Service Fabric позволяет клиентам проходить проверку подлинности с помощью NTLM, а не Kerberos. Корпорация Майкрософт не рекомендует использовать NTLM. Дополнительные сведения см. в разделе Вопросы безопасности для разработчиков.
Везде, где это возможно, следует применять Kerberos вместо NTLM.
Изменения манифеста кластера
В этом разделе предполагается, что у вас уже есть манифест кластера, в котором настроено использование Kerberos для проверки подлинности клиента и сертификатов X.509 для проверки подлинности сервера и шифрования. Дополнительные сведения см. в статье Защита кластера с помощью Безопасность Windows.
Использование REST API с Kerberos
При использовании REST API для взаимодействия с кластером с поддержкой Kerberos REST API не изменяются. URL-адреса, заголовки HTTP, запросы и тела ответа вызова REST останутся без изменений.
Тем не менее необходимо следовать стандартному процессу проверки подлинности HTTP Kerberos и NTLM.
Обратите внимание на следующие условия.
Большинство клиентов HTTP автоматически выполняют этот процесс.
Если известно, что сервер защищен с помощью Kerberos/NTLM, можно начать с шага 3 следующего процесса. При этом будет удален один сетевой прыжок.
REST с процессом проверки подлинности Kerberos
Ниже приведен пример последовательности процесса проверки подлинности Kerberos с помощью REST.
Вызовите REST API без дополнительных заголовков HTTP:
GET http://localhost:19007/Nodes?api-version=6.0 HTTP/1.1 User-Agent: Fiddler Host: localhost:19007Кластер с поддержкой Kerberos ответит с сообщением 401 Unauthorized ("401 Доступ запрещен") и установит для заголовка WWW-Authenticate значение Negotiate:
HTTP/1.1 401 Unauthorized Server: Microsoft-HTTPAPI/2.0 WWW-Authenticate: Negotiate Date: Thu, 09 Jan 2014 08:20:55 GMT Content-Length: 0Теперь клиент должен получить токен, обратившись к своей службе каталогов AD (федеративной или взаимной) с использованием имени субъекта-службы.
Имя субъекта-службы — HTTP\FQDN узла Service Fabric, к которой осуществляется связь.
Маркер, возвращаемый AD, должен использоваться в заголовке авторизации в формате "Negotiate <token>"
GET http://localhost:19007/Nodes?api-version=6.0 HTTP/1.1 User-Agent: Fiddler Host: localhost:19007 Authorization: Negotiate YH8GBisG<…>CSqGSIb3EgECAgYKKwYBBAGCNwICHqI/BD1OVE<…>RNT05EСервер выполнит проверку подлинности токена, и если клиент будет авторизован для выполнения операции, то начнется выполнение запроса.
HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 Date: Thu, 09 Jan 2014 08:38:43 GMT Content-Length: 1457 [{"Name":"Node4","IpAddressOrFQDN":"localhost","Type":"NodeType04","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":false,"UpgradeDomain":"MYUD1","FaultDomain":"fd:\/RACK2","Id":{"Id":"b5bd41bc26a079f4df3791b2b5d42e5"}},{"Name":"Node1","IpAddressOrFQDN":"localhost","Type":"NodeType01","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":true,"UpgradeDomain":"MYUD1","FaultDomain":"fd:\/RACK1","Id":{"Id":"10152272d1e44a94356a41d96dc9b466"}},{"Name":"Node2","IpAddressOrFQDN":"localhost","Type":"NodeType02","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":true,"UpgradeDomain":"MYUD2","FaultDomain":"fd:\/RACK2","Id":{"Id":"15091e9851978afe10f2f3ab37c1d2f0"}},{"Name":"Node5","IpAddressOrFQDN":"localhost","Type":"NodeType05","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":false,"UpgradeDomain":"MYUD2","FaultDomain":"fd:\/RACK1","Id":{"Id":"6e48b9c722325a66f805e2890bb7dd30"}},{"Name":"Node3","IpAddressOrFQDN":"localhost","Type":"NodeType03","CodeVersion":"2.0.283.0","ConfigVersion":"1.0","NodeStatus":1,"NodeUpTimeInSeconds":"4335",NodeDownTimeInSeconds":"0","HealthState":1,"IsSeedNode":true,"UpgradeDomain":"MYUD3","FaultDomain":"fd:\/RACK1","Id":{"Id":"880f1f5072c2c4805e9cb15ec710d083"}}]