2009-12-09 5 views
1

У меня есть веб-служба на основе WSE 3.0, работающая в Windows Server 2003 под IIS 6.0. Я хочу, чтобы процесс веб-сервиса выдавал себя за клиента, который отправляет запрос веб-службы, однако служба не олицетворяет клиента.Как мне получить веб-службу WSE 3.0 для олицетворения личности моего клиента?

Веб-приложение имеет собственный пул приложений, который в настоящее время настроен для работы под идентификатором сетевой службы. Учетная запись компьютера Windows Server 2003 включена для делегирования в Active Directory (по крайней мере, по словам моего ИТ-специалиста). Политика обслуживания WSE (в wse3policyCache.config) выглядит следующим образом:

<policy name="GeneratedServicesPolicy"> 
    <kerberosSecurity establishSecurityContext="false" renewExpiredSecurityContext="true" requireSignatureConfirmation="false" messageProtectionOrder="SignBeforeEncrypt" requireDerivedKeys="true" ttlInSeconds="300"> 
     <protection> 
      <request signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="false" /> 
      <response signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="false" /> 
      <fault signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="false" /> 
     </protection> 
    </kerberosSecurity> 
    <requireActionHeader /> 
</policy> 

служба имеет следующие данные (среди прочих) в его web.config:

<identity impersonate="false"/> 
<authentication mode="Windows"/> 

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

HOST/RD360-2 
HOST/rd360-2.mycompany.com 

Клиент имеет следующий в wse3policyCache.config:

<policy name="KerbClient"> 
    <kerberosSecurity establishSecurityContext="false" renewExpiredSecurityContext="true" requireSignatureConfirmation="false" messageProtectionOrder="SignBeforeEncrypt" requireDerivedKeys="true" ttlInSeconds="300"> 
     <token> 
      <kerberos targetPrincipal="HOST/rd360-2.mycompany.com" impersonationLevel="Impersonation" /> 
     </token> 
     <protection> 
      <request signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="false" /> 
      <response signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="false" /> 
      <fault signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="false" /> 
     </protection> 
    </kerberosSecurity> 
    <requireActionHeader /> 
</policy> 

клиентский код выглядит следующим образом:

static void Main(string[] args) 
{ 
    AddFloatsWSWse client = new AddFloatsWSWse(); 
    client.SetPolicy("KerbClient"); 

    double result = client.AddFloats(2.3, 3.2); 
    Console.WriteLine("Result was: '" + result + "'"); 
} 

Услуги не олицетворяет мою идентификацию клиента. Я использую log4net в сервисе, и когда я прошу его распечатать %username в журнале трассировки ASP.NET, он всегда NT AUTHORITY\NETWORK SERVICE, а не идентификатор пользователя клиента. Есть ли что-то, что я делаю неправильно? Есть ли где-нибудь, где я могу посмотреть, пытается ли WSE попытаться выполнить олицетворение и потерпеть неудачу? Я вижу следующие записи в моем журнале событий (MYDOMAIN и MyUser затемнены здесь):

Event Type: Success Audit 
Event Source: Security 
Event Category: Privilege Use 
Event ID: 576 
Date:  12/9/2009 
Time:  11:07:16 AM 
User:  MYDOMAIN\MYUSER 
Computer: RD360-2 
Description: 
    Special privileges assigned to new logon: 
     User Name: MYUSER 
     Domain:  MYDOMAIN 
     Logon ID:  (0x0,0x4B410AE) 
     Privileges: SeSecurityPrivilege 
       SeBackupPrivilege 
       SeRestorePrivilege 
       SeTakeOwnershipPrivilege 
       SeDebugPrivilege 
       SeSystemEnvironmentPrivilege 
       SeLoadDriverPrivilege 
       SeImpersonatePrivilege 

---------------------------------------------------------------------------------- 

Event Type: Success Audit 
Event Source: Security 
Event Category: Logon/Logoff 
Event ID: 540 
Date:  12/9/2009 
Time:  11:07:16 AM 
User:  MYDOMAIN\MYUSER 
Computer: RD360-2 
Description: 
    Successful Network Logon: 
     User Name: MYUSER 
     Domain:  MYDOMAIN 
     Logon ID: (0x0,0x4B410AE) 
     Logon Type: 3 
     Logon Process: Kerberos 
     Authentication Package: Kerberos 
     Workstation Name: 
     Logon GUID: {OBFUSCATED} 
     Caller User Name: - 
     Caller Domain: - 
     Caller Logon ID: - 
     Caller Process ID: - 
     Transited Services: - 
     Source Network Address: - 
     Source Port: - 

И в моем WSE файле трассировки Я вижу:

<processingStep description="Entering SOAP filter Microsoft.Web.Services3.Design.RequireSoapHeaderAssertion+RequireSoapHeaderFilter" /> 
<processingStep description="Exited SOAP filter Microsoft.Web.Services3.Design.RequireSoapHeaderAssertion+RequireSoapHeaderFilter" /> 
<processingStep description="Entering SOAP filter Microsoft.Web.Services3.Design.KerberosAssertion+ServiceInputFilter" /> 
<processingStep description="Exited SOAP filter Microsoft.Web.Services3.Design.KerberosAssertion+ServiceInputFilter" /> 

так, по крайней мере я знаю Kerberos расширения обрабатывают мои заголовки Kerberos.

Редактировать: Затем мой веб-сервис использует запатентованную клиентскую библиотеку связи для вызова на другой сервер с использованием SSPI/IWA (назовем этот третий сервер сервером foo). Я хочу, чтобы он использовал идентификатор клиента, когда он делает этот второй вызов на сервере foo. Это означает, что эта клиентская коммуникационная библиотека вызывает AcquireCredentialsHandle и InitializeSecurityContext с использованием SPN сервера foo и другой службы. В этом конкретном случае сервер foo фактически работает на том же компьютере, что и веб-служба WSE (поэтому он использует SPN mycompany/rd260-2). Поскольку этот второй прыжок относится к тому же самому компьютеру, я ожидал бы, что это будет использовать NTLM, но он все равно должен олицетворять идентификацию пользователя клиента веб-сервиса, не так ли? В журналах foo-сервера я вижу, что он принимает соединение, использует предоставленный контекст безопасности IWA и сообщает мне, что на основе этого контекста безопасности пользователь-подключитель составляет rd36-2$, который является учетной записью машины, поскольку веб-служба WSE работает в IIS под идентификатором сетевой службы (который, в свою очередь, связан с машинной учетной записью). В журналах foo-сервера после получения контекста безопасности IWA я в конечном итоге хочу видеть личность пользователя, отправившего запрос веб-службы. Было бы полезно перенести сервер foo на другую машину, чтобы увидеть, имеет ли это какое-то отношение к этому?

ответ

2

Маркер Kerberos, используемый с WSE 3, представляет собой механизм безопасности на уровне сообщений и только аутентифицирует клиента. На самом деле это не изменяет контекст безопасности, как в IWA, поэтому вы не заметите ничего другого в журнале трассировки как такового. Для того, чтобы фактически олицетворение клиента, вы должны:

  • Включить олицетворение на маркер безопасности с impersonationLevel="Impersonation" на <kerberos> элемент (который вы уже сделали); и
  • Создайте свой WebMethod WindowsImpersonationContext на основе идентификационной маркировки.

Пример:

WindowsIdentity identity = 
    (WindowsIdentity)RequestSoapContext.Current.IdentityToken.Identity; 
WindowsImpersonationContext impersonationContext = null; 
try 
{ 
    impersonationContext = identity.Impersonate(); 

    // Perform your work here 
    // ... 
} 
finally 
{ 
    if (impersonationContext != null) 
    { 
     impersonationContext.Undo(); 
    } 
} 
+0

Спасибо за ваши предложения! Я добавил несколько подробностей к моему вопросу, излагая работу, выполняемую службой. В моем журнале трассировки я все еще вижу, что процесс работает как NT Authority \ Network Service, даже после того, как маркер Kerberos обрабатывается инфраструктурой WSE. Но, возможно, исходя из вашего комментария, я никогда не ожидал увидеть личность пользователя в журнале даже после успешного олицетворения? Я думал, что напомнил, что когда вы выполняете IWA транспортного уровня через IIS вместе с олицетворением, вы видите идентификатор пользователя клиента в журналах трассировки. Разве это просто отличается от TLS IWA? – Zach

+0

Насколько я знаю, IWA здесь не важна. Клиенты WSE подключаются анонимно и аутентифицируются/шифруются/подписываются на уровне сообщений. Если память используется, вы не увидите олицетворенного пользователя в журнале трассировки. FYI - WCF делает WA совершенно по-другому, Microsoft изменила его, потому что версия WSE была настолько хакерской. – Aaronaught

+0

Кроме того, если выполненная работа связана с вызовом в некоторую проприетарную библиотеку с поддержкой SSPI, вполне возможно, что библиотека пытается получить свой контекст где-то, кроме вызывающего. Как я уже упоминал, сначала попробуйте очень простой тест, то есть настройте ACL на файл где-то с правами доступа, предоставленными пользователю, которому вы хотите выдавать себя, затем попробуйте получить доступ к файлу в вашем методе WebService. – Aaronaught

0

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

После этого ваша аутентификация завершится неудачей и не переключится на NTLM.