2009-07-07 2 views
2

В Silverlight 3 и WPF есть приложения, которые взаимодействуют с веб-службами данных (на основе WCF). Необходимо защищать веб-службы данных. Только известные пользователи должны иметь доступ к данным. Решение будет работать в локальной сети без доступа извне.Связывание маркера безопасности с конкретной клиентской машиной

Клиент связывается первым с аутентификационным веб-сервисом (с указанием имени пользователя и пароля) через SSL и получает маркер безопасности. После этого этот токен передается веб-службам данных для проверки пользователя и получения доступа к данным.

Возникает вопрос: как ограничить использование токена безопасности машиной, для которой она была изначально выпущена?

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

Есть ли какие-либо шаблоны для такого рода вещей?

ответ

2

Там нет 100% способа связать маркер безопасности к машине :(

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

у меня есть пара мыслей:.

  • для ваших токенов, вы, вероятно, хотите использовать Аутентификация форм. По умолчанию он выдаст tok как файлы cookie, но которые можно настроить. Еще одна интересная вещь заключается в том, что он автоматически истекает (снова, настраивается) токены. Есть много возможных ошибок, которые могут быть сделаны с помощью ваших жетонов/системы безопасности, и использование существующей системы даст вам совершенно новую форму. Там даже есть WCF service for authentication.
  • Если вы действительно серьезно относитесь к ограничению звонков с определенных компьютеров, вы можете использовать 2-way SSL с сертификатами на клиентской машине. Это все еще не безупречное решение (кто-то из хорошая команда все еще может делиться сертификатами с кем-то на плохой команде ), но он гарантирует, что у клиента есть сертификат, который вы распространяете. Недостатком является то, что этот материал является pain in the neck to configure.

Разъяснение: Попробуйте мысленный эксперимент. Даже если вы могли бы вызвать Win32 API из Silverlight, чтобы получить информацию о машине и использовать ее для токена, у вас все еще нет надежного решения. Ваши вызовы API могут быть виртуализированы.В этом случае вся ваша клиентская машина может быть виртуализирована. Для доказательства этого см. Документ Darknet или любую существующую систему DRM. Это не winnable.

Вот как вы можете ограничить ущерб кого-то из хорошей команды, давая кому-то из плохой команды ваш токен. Вы истекаете токены через определенное время. Тогда сценарий, с которым вы имеете дело, таков: Пользователь предоставляет законный пользователь/пропуск, и поэтому у них есть доступ на определенное количество времени (10 минут, 10 часов, 10 дней и т. Д.), И вам все равно независимо от того, звонят ли они из Silverlight, AJAX или Atari 2600. В конце концов, они просто доказали, что они были в хорошей команде с пользователем/pass. Это игра, которую вы можете выиграть.

+0

Мы хотим иметь решение для единого входа для различных типов приложений (win-web-silverlight). Это означает, что необходимо перенести токен между ними. В результате было бы полезно ограничить использование токена только одной машиной. В этом случае, если кто-то (от плохой команды) получит токен, его будет трудно (повторно) использовать. – IuriiZ

+0

Механизм, используемый для ограничения повторного использования токена, - это срок действия токена. Я уточню выше. –

0

Если у клиентов есть системный доступ, попробуйте прочитать серийный номер жесткого диска, сетевой адрес сетевой карты, серийный номер материнской платы и т. Д., Объединить их и создать хэш из него. Затем отправьте этот хэш вместе с учетными данными, чтобы получить токен безопасности. Хеш должен быть сохранен и на сервере. Затем по всем последующим запросам клиент отправляет маркер безопасности вместе с только что сгенерированным машинным хешем. Сервер проверяет как учетные данные, так и хэш. В частности, был ли маркер безопасности сгенерирован с использованием этого конкретного хэша.

Некоторое количество работы, но это выполнимо, и это весело.

+0

Silverlight не может получить доступ к базовой системе. Кроме того, если кто-то может получить маркер безопасности вместе с генерируемым машинным хешем (службы не защищены SSL), все равно можно получить доступ к веб-службам данных с другого компьютера, представляющего токен + хеш. – IuriiZ

+0

Отпечаток машины может быть создан только с использованием машинных данных, что означает некоторую информацию об оборудовании, а не установку ОС/программного обеспечения. Если Silverlight не сможет получить доступ к какой-либо из них, тогда логика подсказывает, что ваша идея бесполезна. – User

Смежные вопросы