Решение избежать двойного перехода от клиента> веб-службы> SQL Server

Question

Мой проект предусматривает подключение пользователя от клиента к веб-службе, а затем веб-службы к SQL Server.Веб-службы и SQL Server находятся на разных компьютерах.Из-за требований безопасности мы не можем использовать смешанный режим в SQL Server, только проверку подлинности Windows.

Мы испытываем проблему «двойного перехода» между веб-службой и SQL Server.Мы используем проверку подлинности NTLM и не хотим настроить Kerberos из-за издержек и кривой обучения.Мы также не хотим, чтобы веб-служба и SQL Server находились на одном компьютере.

Насколько я понимаю, все наши требования делают этот сценарий невозможным для решения.Тем не менее, разработчик выступил с таким предложением:

1) Отправьте имя пользователя и пароль windows с клиента на веб-службу с шифрованием SSL

2) Каким-то образом преобразовайте имя пользователя и пароль windows вмаркер безопасности, который может быть аутентифицирован SQL Server

Чтобы провести аналогию, похоже, что мы выполняем RUNAS в коде C # при подключении к SQL Server.Для веб-службы не будет аутентификации, только через SQL Server.

Мои вопросы:

1) Возможно ли предлагаемое решение?

2) Если так, как это будет сделано?

3) Есть ли веб-ресурсы, помогающие мне понять, как это можно сделать?

Answer 1

Нет, это невозможно.Клиентский процесс не имеет доступ к паролю пользователя и, следовательно, не может отправить его на уровень веб-службы.Клиент должен был бы явно запросить у пользователя его пароль. Если клиентский процесс имеет пароль и желает отправить его в веб-службу, то теоретически WebService может создать токен для этого пользователя / пароля (используя LogonUser ) изатем подключитесь к SQL Server, используя этот токен.Это так называемое решение настолько пронизано множеством проблем безопасности, что обсуждать не стоит.Если ваша команда настаивает на этом, создайте веб-сервис, который сделает это, попросите члена группы подключиться к нему, и как только вы получите его учетные данные (он отправит вашей службе свой пароль , помните?)подключитесь к серверу обмена и отправьте письмо генеральному директору с текстом «Уволите меня, я идиот».Или смените свой прямой депозит банка и счет в HR.Используйте свое воображение ... Надеюсь, теперь немного яснее, почему путь, который вы предлагаете, является очень плохой идеей .

Просто используйте Kerberos.

Кстати, если вам требуется аутентификация на серверной стороне из-за правительственных постановлений, имейте в виду, что аутентификация и аудит всегда поставляются с требованием «безотказности» и отправкой пароля навеб-сервис, поэтому он аутентифицируется на вашем сайте, явно противоречит этому требованию, поскольку веб-сервис может выполнять любую операцию, которую он хочет маскировать под пользователя.Это то, что делегирование Kerberos является ограниченным делегированием.

Answer 2

Это не могло быть сделано.Подумайте об этом, если бы приложения могли просто генерировать токены безопасности таким образом, что было бы хорошо?Вам понадобится Kerberos, чтобы преодолеть эту проблему.

Редактировать: Аналогия с runas не применяется в случае, когда клиент пытается последовательно пройти аутентификацию в двух системах, поскольку runas требует только одного прыжка, даже когдавы переключаете пользователя.