Ограничение доступа к внутренним службам WCF - PullRequest
3 голосов
/ 15 июня 2011

У нас есть несколько служб WCF, размещенных в приложении asp.net на IIS. Мы получаем все больше и больше услуг, используемых для внутренней связи (между нашими собственными системами, где клиент может находиться на том же сервере или на других серверах). Теперь нам нужно каким-то образом обезопасить эти сервисы.

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

Наша текущая мысль: У нас уже включен SSL, и у нас есть публичный сертификат для сервера. Наш текущий план состоит в том, чтобы включить защиту с помощью: clientCredentialType = "UserName", где у нас есть пользовательский валидатор, который просто проверяет имя пользователя / пароль, которые мы определили (очень похоже на ключ API).

Вопрос № 1: Есть ли лучший способ? Сценарий звучит просто, и я чувствую, что нам не хватает очевидного решения

Вопрос № 2: Если мы сделаем это таким образом, будет ли у нас достаточно SSL-сертификата или мы должны создать какие-либо другие сертификаты?

Некоторый контекст: .net 4, IIS 7, у нас есть доступ к серверу. Клиенты / сервисы могут быть расположены на разных серверах.

Обновление 1: Клиент может находиться в совершенно другой сети. У нас есть другие системы, размещенные в других местах, которые также должны иметь возможность вызывать эти службы.

1 Ответ

3 голосов
/ 15 июня 2011

Как я понимаю ваш сценарий, у вас есть все ваши серверы / сервисы в вашей сети / домене windows, не так ли? В таком случае я бы не использовал UserName аутентификацию. Палка с Windows безопасности и HTTPS.

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

  • Стандартный пользовательский уровень безопасности .NET на основе ролей PrincipalPermission или PrincipalPermissionAttribute. Это имеет недостаток в том, что вы должны жестко закодировать авторизацию для своих сервисов. Только пользователи из определенной группы окон смогут получить доступ к услуге
  • Можно надеяться, что прежний подход (не проверенный с WCF, но хорошо работающий с ASP.NET) с поставщиком ролей ASP.NET. В таком случае вы можете использовать настраиваемую роль, отличную от Windows, в разрешениях и использовать AutorizationStoreRoleProvider (AzMan) для сопоставления пользователей домена или групп доменов с вашей настраиваемой ролью. Опять же, это требует жесткого кодирования как минимум разрешений для пользовательских ролей.
    Как использовать Диспетчер авторизации с ASP.NET 2.0
    Как использовать поставщик ролей ASP.NET в WCF
  • Создайте пользовательский ServiceAuthorizationManager, где вы будете использовать утверждения для роли Windows для авторизации пользователя. Преимущество этого подхода заключается в том, что вы можете добавить диспетчер авторизации через конфигурацию, чтобы вам не приходилось трогать какой-либо код ваших служб.
    Как создать собственный AuthorizationManager для службы WCF
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...