Как ограничить доступ к службе WCF с помощью общего ключа

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

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

Как мне настроить службу для реализации такого рода безопасности? Сколько настроек необходимо?


security service wcf
person Columbo    schedule 15.09.2009    source источник

Ответы (3)


arrow_upward
3
arrow_downward

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

См. эти статьи для получения информации о том, как этого добиться:

По сути, вам нужно обернуть вызов службы в OperationContext — вот и все, не требуется ClientMessageInspector и другие хитрости :-)

 using (OperationContextScope scope = new OperationContextScope(proxy))
 {
     Guid myToken = Guid.NewGuid();

     MessageHeader<Guid> mhg = new MessageHeader<Guid>(myToken);
     MessageHeader untyped = mhg.GetUntypedHeader("token", "ns");

     OperationContext.Current.OutgoingMessageHeaders.Add(untyped);

     proxy.DoOperation(...);
  }

а на стороне сервера вы можете просто проверить коллекцию IncomingMessageHeaders:

Guid myToken = OperationContext.Current.
                 IncomingMessageHeaders.GetHeader<Guid>("token", "ns");

Марк

person marc_s    schedule 15.09.2009
comment
Привет, Марк, если предположить, что у Columbo не было другой настройки безопасности для службы, будет ли это решение по-прежнему приводить к шифрованию содержимого сообщения WCF? - person Xiaofu; 09.03.2012
comment
@Xiaofu: по умолчанию (если вы явно не отключили его) все сообщения WCF шифруются и имеют цифровую подпись. - person marc_s; 09.03.2012

arrow_upward
2
arrow_downward

Я бы попросил клиента отправить ключ в качестве дополнительного заголовка сообщения и создать IDispatchMessageInspector для проверки заголовка и, при необходимости, отклонить его. В этой статье Code Project описывается часть фильтра на основе IP-адреса.

person Maurice    schedule 15.09.2009
comment
Спасибо, мне нравится внешний вид этого подхода. Я немного поработал над этой идеей, и похоже, что мне следует использовать IClientMessageInspector для вставки ключа на стороне клиента, реализованного как поведение конечной точки. А затем на стороне сервера у меня будет поведение, реализующее IDispatchMessageInspector, которое проверяет ключ. И последнее: есть ли что-нибудь готовое в wcf, которое достигло бы аналогичной цели, но без необходимости в пользовательском поведении? - person Columbo; 15.09.2009
comment
Если вы не используете функции безопасности WCF, вы можете использовать их для этого подхода. В этом случае я бы создал сертификат для каждого клиентского приложения и в каждой службе проверил наличие разрешенных клиентских сертификатов. И я полагаю, вы могли бы сделать то же самое с именем пользователя/паролем, хотя это также заставит вас использовать HTTPS. - person Maurice; 15.09.2009
comment
Спасибо, аутентификация пользователя/пароля была чем-то, что мы рассматривали раньше, но у нас было несколько проблем с ssl и нашей конфигурацией сети, что означало, что мы начали искать другие способы выполнения требования. Из того, что я узнал сегодня, я думаю, что буду использовать этот подход отправки общего ключа в заголовке. Так что теперь осталось сделать небольшой тестовый проект :) - person Columbo; 15.09.2009

arrow_upward
0
arrow_downward

Если вы сделаете это с помощью ключа, вы измените контракт службы, включив в него поле, в которое будет помещен ключ. Затем проверьте значение ключа на стороне сервера.

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

person Shiraz Bhaiji    schedule 15.09.2009
comment
Это не очень хорошая идея - таким образом вам придется изменить свои контракты, и вы загрязните свою фактическую бизнес-логику инфраструктурой/управляющими полями. Я бы не рекомендовал этот подход. - person marc_s; 15.09.2009