WCF. Узнаём имя ползователя

[Alexus]

У меня есть сервис - тоесть есть контракт службы, реализованное поведение службы, создан ServiceHost, все EndPoint-ы.
Всё это работает.
Вопрос в том, как узнать имя юзера, под которым он подключился к службе, во время выполнения одного из методов поведения службы (если конечно логин в данной службе требуется)

Добавлено 18.03.08, 05:38
И вообще - правильно ли ставить в зависимость возвращаемое значение не только от параметров, но и от такого вот "контекста"

[Alexus]

нашёл.

OperationContext.Current.ServiceSecurityContext

[PIL]

Цитата Alexus @ 18.03.08, 05:37

И вообще - правильно ли ставить в зависимость возвращаемое значение не только от параметров, но и от такого вот "контекста"

-
ты делаешь какую-то ролебазированную систему защиты серверного кода?

[Alexus]

Цитата PIL @ 18.03.08, 07:34

ты делаешь какую-то ролебазированную систему защиты серверного кода?

много буков...

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

Какие то изменения можно делать всем, какие то - только привелегированным пользователям.
Я думаю, что идентификацию пользователя возьму из винды. А его права - лучше тоже в домене назначать.

Вот и хочется чтобы при вызове сервер проверял что за юзер и можно ли ему делать то, что он делает.

[PIL]

Цитата Alexus @ 18.03.08, 08:07

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

- понятно. Я делал что-то похожее. Проверку привилегий и пользователей сделал на своей реализации IOperationInvoker + своих атрибутах. Только у меня пользователи были не виндовые, контекст хранения данных пользователей тоже свой.

[Alexus]

Да, контекст безопасности, похоже, лучше действительно свой писать, а вот аутентификация - виндовую удобней юзать..

[walker]

мне тоже понадобилось узнать имя пользователя.
OperationContext.Current возвращает null
на всякий случай у интерфейса добавил атрибут
[ServiceContract (SessionMode = SessionMode.Required)]
не помогло. Как быть? чего не хватает?

[spicard]

Не хватает режима аутентификации, в котором работает твой WCF сервис. Если клиентом является веб-приложение, то обычно используют режим UserName при котором передаются логин, пароль (и домен) пользователя. Если клиентом является внутрикорпоративное приложение, то удобнее использовать Windows аутентификацию. Для защищенного канала возможно аутентифицировать клиента по его сертификату.

Определи какой случай у тебя, руководства по настройке найдешь здесь: P&P: WCF Security Guidance - How To

[walker]

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

[spicard]

Так не включай имперсонацию, передавай информацию о клиенте при помощи свойства ClientCredentials перед каждым вызовом

[TerraGhost]

Господа, 2 дня мучаюсь, скажите, что не правильно? Вот сервер:

  <system.serviceModel>
    <services>
      <service behaviorConfiguration="MyServiceBehavior" name="MyService">
        <endpoint address="" binding="wsHttpBinding" contract="IMyService" bindingName="wsHttpEndpointBinding">
          <identity>
            <dns value="" />
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="MyServiceBehavior">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <bindings>
      <wsHttpBinding>
        <binding name="wsHttpEndpointBinding">
          <security mode="TransportWithMessageCredential">
            <transport clientCredentialType="None" />
            <message clientCredentialType="UserName" />
          </security>
        </binding>
      </wsHttpBinding>
    </bindings>
  </system.serviceModel>

И клиент:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <bindings>
      <wsHttpBinding>
        <binding name="wsHttpEndpointBinding_IMyService">
          <security mode="Message">
            <message clientCredentialType="UserName" />
          </security>
        </binding>
      </wsHttpBinding>
    </bindings>
    <client>
      <endpoint address="http://localhost:2646/MyService.svc" binding="wsHttpBinding"
          bindingConfiguration="wsHttpEndpointBinding_IMyService" contract="ServiceReference1.IMyService"
          name="wsHttpEndpointBinding_IMyService">
        <identity>
          <dns value="" />
        </identity>
      </endpoint>
    </client>
  </system.serviceModel>
</configuration>

using (ServiceReference1.MyServiceClient client = new ConsoleApplication2.ServiceReference1.MyServiceClient ())
            {
                client.ClientCredentials.UserName.UserName = "abc";
                client.ClientCredentials.UserName.Password = "def";
 
                int summ = client.Summ (3, 4); // Ошибка
            }

Вылетает ошибка

Secure channel cannot be opened because security negotiation with the remote endpoint has failed. This may be due to absent or incorrectly specified EndpointIdentity in the EndpointAddress used to create the channel. Please verify the EndpointIdentity specified or implied by the EndpointAddress correctly identifies the remote endpoint.

Как сконфигурировать эту идентити у конечной точки? И где собственно отлавливать авторизацию клиента со стороны сервера?

А лучше может кто кинет солюшен с простой связкой сервер-клиент и примером в них авторизации логин-пароль (UserName) для обычного wcf-сервиса под wsHttpBinding

[vol]

Да, не так то просто заставить работать WCF (wsHttpBinding + UserName auth), без установки сертификата не обойтись. Хотя встречал посты о том, что сертификат можно не устанавливать на клиенте, но лично не пробовал.

У MS есть куча примеров с простыми солюшенами (here). Смотри пример UserNamePasswordValidator в Extensibility -> Security

Сообщение отредактировано: vol - 26.08.09, 12:55

[TerraGhost]

Похоже, что оно ещё и IIS принудительно требует.

[spicard]

Цитата TerraGhost @ 26.08.09, 10:34

А лучше может кто кинет солюшен с простой связкой сервер-клиент и примером в них авторизации логин-пароль (UserName) для обычного wcf-сервиса под wsHttpBinding

Конфигурирование сервиса как раз для данной ситуации описано здесь:
How To – Use wsHttpBinding with UserName Authentication and TransportWithMessageCredentials in WCF
Другое дело, что при использовании режима TransportWithMessageCredentials обязательно требуется сертификат, т.к. данные пользователя будут передаваться в заголовках HTTP.

[TerraGhost]

> Configure the SQL Server Membership Provider.
> Create a WCF service hosted in Internet Information Services (IIS).


Добавлено 28.08.09, 11:17
Можно, без этой прелести? Хочу разворачивать хостинг WCF сервиса обычным косольным приложением или службой

[spicard]

По поводу Membership Provider здесь необходимо знать требования - если на стороне хоста нужно резолвить роли\профиль пользователя, тогда без хранилища и провайдера не обойтись, правда можно использовать свой. Если же безопасноть планируется ограничить только на уровне HTTP, тогда переключи режим на Transport и используй Windows Authentication, как описано здесь:
How To – Use wsHttpBinding with Windows Authentication and Transport Security in WCF
How To: Use netTcpBinding with Windows Authentication and Transport security in WCF
Использовать Transport security совместно с UserName Authentication вроде не запрещено, но не кошерно.

А по поводу хостинга точно не скажу - IIS используется для установки SSL соединения.