Защита веб-службы - PullRequest
       11

Защита веб-службы

1 голос
/ 21 апреля 2010

Я унаследовал обычное трехуровневое веб-приложение с ASP.net 2.0 для пользовательского интерфейса, веб-сервисами .Net (ASMX) на среднем уровне и SQL Server 2005 для БД. В настоящее время это приложение для внутренней сети, единственными пользователями которого являются сотрудники компании. В настоящее время приложение использует проверку подлинности Active Directory (AD).

На экране входа в систему пользователю предоставляется диалог имени пользователя / пароля. Средний уровень делает простой вызов AD, чтобы проверить имя пользователя / пароль. Если все в порядке, тогда guid sessionId генерируется и отправляется обратно в пользовательский интерфейс. Этот идентификатор сеанса затем передается при каждом последующем вызове из пользовательского интерфейса в течение сеанса. Все методы среднего уровня сначала проверяют правильность sessionID в сравнении с простой таблицей сеансов в SQL Server перед обработкой запроса.

Теперь мне нужно сделать веб-сервисы среднего уровня приложения доступными для нового пользовательского интерфейса, который будет доступен для общедоступного Интернета. Мне не нужно беспокоиться об аутентификации, потому что это будет управляться новым пользовательским интерфейсом. Однако я не хочу оставлять веб-сервисы полностью открытыми без какой-либо безопасности. Я просто хочу быть уверен, что система, вызывающая сервисы, имеет разрешение на это. Я не хочу обременять новый пользовательский интерфейс необходимостью поддерживать сессионные идентификаторы, используемые в настоящее время.

Есть ли мнения о том, как лучше защитить сервисы при вызове из нового интерфейса? Я думаю, что я мог бы использовать сертификаты x509, но я делал это раньше, поэтому я не знаю ни о каких недостатках (производительности?) Или о способах реализации.

Новый пользовательский интерфейс был разработан с использованием .Net 3.5. Мы можем установить .Net 3.5 на среднем уровне, поэтому я думаю, что мы могли бы извлечь выгоду из использования WCF?

1 Ответ

0 голосов
/ 22 апреля 2010

Я не верю, что это проблема, которая подходит для криптографии. Было бы лучше ограничить доступ к вашему веб-сервису, используя ограничение IP. Если эти данные передаются по небезопасному соединению, такому как открытый Интернет, то вы могли бы использовать ssl для проверки клиента и сервера, а также для обеспечения безопасности передаваемых данных. Вы также можете использовать VPN, который, вероятно, проще всего реализовать.

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

Одним из решений является наличие активного каталога запросов веб-службы ASMX для каждого запроса. Если сервер AD не находится под большой нагрузкой, это должно быть хорошо. Имейте в виду, что AD - очень эффективная база данных сама по себе.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...