WCF: связь между NetworkCredential и олицетворением - PullRequest
Новая
       13

WCF: связь между NetworkCredential и олицетворением

2 голосов
/ 26 марта 2009

У меня есть служба WCF, размещенная в IIS 7 в пуле приложений по умолчанию в интегрированном режиме с отключенным анонимным доступом и включенной аутентификацией Windows.

Я добавил следующий атрибут в реализацию метода для моего интерфейса. 

[OperationBehavior(Impersonation = ImpersonationOption.Required)]

Если я не предоставляю учетные данные сети при вызове моей службы, я получаю ожидаемое поведение в следующем:

ServiceSecurityContext.Current.WindowsIdentity.Name = myDomain \ myUser
ServiceSecurityContext.Current.PrimaryIdentity.Name = myDomain \ myUser
Thread.CurrentPrincipal.Identity.Name = myDomain \ myUser
Я могу подключиться к базе данных в удаленной системе, используя SSPI и аутентификацию myDomain \ myUser.
WindowsIdentity.GetCurrent (). Name = myDomain \ myUser
Я могу использовать Thread.CurrentPrincipal.IsInRole (), чтобы проверить, что пользователь в роли.
Я могу использовать WindowsIdentity.GetCurrent (). Groups для получения списка групп для пользователя.

Но если я предоставлю сетевые учетные данные, используя следующее: 

var networkCredential = new NetworkCredential(user, pwd, dom);
base.ClientCredentials.Windows.ClientCredential = networkCredential;
base.ClientCredentials.Windows.AllowNtlm = true;      
base.ClientCredentials.Windows.AllowedImpersonationLevel 
          = System.Security.Principal.TokenImpersonationLevel.Delegation;

Тогда все вышеперечисленное одинаково, за исключением соединения с базой данных, и две из перечисленных групп различны. Соединение с базой данных выполняется с использованием учетной записи NT Authority \ Anonymous. Использование NetworkCredentials помещает пользователя в группу NT Authority \ Network, а не в NT Authority \ Interactive, и дополнительно удаляется ЛОКАЛЬНАЯ группа.

Моя цель - установить соединение с базой данных с использованием учетных данных, переданных NetworkCredential, и мы будем благодарны за любые советы.

Держатель Шейна

1 Ответ

0 голосов
/ 26 марта 2009

Походит на типичные проблемы двойного прыжка.

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

Во втором сценарии он не использует Kerberos из-за предоставленного пользователя / прохода и не поддерживает получение токена делегирования.

Единственный другой способ получить токен делегирования на удаленном сервере, о котором я знаю, - это использовать базовую аутентификацию (с SSL), полная боль.

В отношении вопроса о двойном прыжке для учетных данных

...