Как безопасно аутентифицировать вызывающую сборку метода службы WCF?

Question

Текущая ситуация такова: у нас есть производственная служба WCF .net 3.5, используемая несколькими приложениями в организации по сравнению с wsHttpBinding или netTcpBinding.Аутентификация пользователя выполняется на транспортном уровне с использованием встроенной безопасности Windows.Эта служба имеет метод Foo(string parameter), который может вызываться только членами указанных групп AD.Строковый параметр обязателен.

В игру вступило новое клиентское приложение (.net 3.5, консольное приложение C #), что исключает необходимость использования строкового параметра.Однако только вызовы из этого конкретного приложения должны позволять пропускать строковый параметр.Идентификатор вызывающей стороны клиентского приложения все еще должен быть известен серверу, поскольку все еще действует ограничение группы AD (исключая олицетворение на стороне клиента).

Я нашел способ передать«свидетельство» вызывающей (строго именованной) сборки в заголовках сообщений , но этот метод явно небезопасен, поскольку «свидетельство» может быть легко подделано.Кроме того, CAS (защита доступа к коду) кажется возможным решением, но я не могу понять, как использовать CAS в этом конкретном сценарии.

Есть ли у кого-нибудь предложения о том, как решить эту проблему?проблема?

Редактировать: Я нашел другую тему на эту тему ;очевидно, вывод, что это просто невозможно реализовать безопасным способом.

Answer 1

Вы можете получить адрес абонента:

 RemoteEndpointMessageProperty clientAddress = 
    OperationContext.Current.IncomingMessageProperties[RemoteEndpointMessageProperty.Name] 
as RemoteEndpointMessageProperty;
           string address = clientAddress.Address;

Answer 2

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

таким образом, вы все равно можете получить как Windows a = uthentication, так и настраиваемое решение, сохраняя при этом свои атрибуты для методов безопасности (я предполагаю, что вы реализуете это таким образом.)

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

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