Аутентификация + аутентификация клиента Silverlight в веб-сервисе WCF

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

Веб-сервис существует, и сейчас это .asmx, но мы собираемся обновить его до WFC.

Пока что, прочитав множество блогов по WCF и авторизации, я пришел к этой идее:

  1. Каждый клиент Silverlight имеет ключ клиента где-то в своей конфигурации.
  2. Сервер веб-службы защищен протоколом SSL, поэтому идентификатор клиента зашифрован как параметр веб-службы.
  3. Аутентификация осуществляется с помощью клиентского ключа.
  4. Авторизация осуществляется через клиентский ключ.

Насколько я понимаю, я думаю, что это должно быть безопасно, но, пожалуйста, не стесняйтесь проделывать дыры!

Единственное, что меня беспокоит, так это то, что мои исследования показывают, что использование WCF для аутентификации и авторизации так сильно нравится, но мне это кажется слишком сложным для того, что мне нужно! Не говоря уже о понимании того, как сложные файлы конфигурации клиента будут работать для приложения Silverlight, обращающегося к службе WCF.

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

Кажется ли моя идея безопасной и разумной, или мне следует продолжать изучение WFC, поскольку фреймворк - лучшее решение?

Если для обеспечения безопасности предпочтительнее фреймворк WCF, можете ли вы дать мне какой-либо совет высокого уровня относительно того, какой поток мне понадобится для защиты моей веб-службы?

Будем рады услышать советы и опыт людей! :)

Большое спасибо!

Энди


person Andy    schedule 07.01.2011    source источник


Ответы (1)


Этот способ небезопасен, потому что silverlight - это технология на стороне клиента, поэтому и SL-контроль, и их конфигурация хранятся на пользовательском компьютере. Таким образом, любой пользователь может свободно получить доступ / изменить ключ.
Пользовательские сеансы - наиболее безопасный способ решения вашей задачи.
Например:
Аутентификация / авторизация могут быть реализованы с использованием стандартных (или пользовательских, вы можете свободно реализовать некоторый конкретный поставщик) ролей / поставщиков членства. После аутентификации клиента он получает токен сеанса, созданный сервером (например, guid). Одинаковые идентификаторы хранятся в базе данных на стороне сервера (например, в базе данных, в которой хранятся все роли, пользователи и т. Д.).
У каждого токена сеанса истек срок действия (используйте агенты / задачи / планировщики БД для удаления ключей с истекшим сроком действия из базы данных).
Таким образом, каждый раз, когда клиент запрашивает какой-либо ресурс, он отправляет на сервер свой токен сеанса, а также другие параметры запроса. После получения запроса сервер ищет тот же токен сеанса в БД и, если токен существует, предоставляет доступ к запрошенному ресурсу. В противном случае аутентификация не удастся.

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

person Igor V Savchenko    schedule 07.01.2011
comment
Ах, хороший момент в том, что SL является клиентской стороной! Совершенно забыл о последствиях. Думаю, я понимаю вашу идею, мне нужно еще немного подумать об этом еще немного в понедельник! :) - person Andy; 08.01.2011