Создание лицензии по сайту (Алгоритм) - PullRequest
2 голосов
/ 28 июня 2011

Я хотел бы предоставить в качестве услуги XML-каналы владельцам сайтов. Сам файл XML будет предоставлен через веб-сервис (.asmx)

Проблема в том, что клиент может свободно распространять ссылку на канал XML.

Так что я подумал о создании "по лицензии на сайт". Владелец сайта-клиента признает мне сайты, которые будут запрашивать каналы XML. Таким образом, XML-каналы будут предоставляться для конкретных запросов http.

P.S. Я знаю, что вы можете изменить заголовки и так далее ... Но я хотел бы реализовать решение, чтобы "замедлить ход событий" и чувствовать себя лучше!

Не могли бы вы предоставить лучший алгоритм лицензирования? Как я могу защитить каналы XML от их свободного распространения?

Ответы [ 3 ]

4 голосов
/ 03 июля 2011

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

Но, в основном, защищайте содержимое с помощью токена, специфичного для места (т. Е. Пароля).

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

Отслеживание входа в систему и поиск злоупотреблений (запросы, поступающие с разных IP-адресов, запросы, поступающие с высокой скоростью и т. Д.).

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

2 голосов
/ 05 июля 2011

Вы можете использовать решение на основе сертификатов (инфраструктура PKI): вы создаете свои собственные сертификаты, которые отправляете своим клиентам (каждый клиент получает свой собственный), и проверяете его, используя логику на стороне сервера, аналогичную описанной здесь: ASP.NET WebForms: реализация аутентификации PKI . Это не пример ASMX, но логика модуля Http такая же.

Преимущество заключается в том, что пользователям не нужно будет вводить пароль, поскольку их браузер должен иметь возможность представить сертификат по запросу сайта.

Конечно, пользователи по-прежнему могут копировать и отправлять сертификаты другим пользователям, поэтому вам все равно понадобится какой-то механизм мониторинга, например, на основе IP-адреса (даже если он не на 100% защищен, это лучше, чем ничего). Как только вы обнаружили, что сертификат кажется мертвым (используется слишком многими людьми), вы можете пометить его, например, как недействительный на вашем сервере, и отправить новый законному пользователю.

0 голосов
/ 08 июля 2011

У меня есть система лицензий, близкая к этому, я хочу предоставить доступ к сервису для определенных файлов XSL и определенных веб-страниц, так как он обрабатывает xsl на основе тегов http из URL, чтобы сделать это, я взял URL-адрес реферера и сравнение с разрешенным URL-адресом вместе с запрошенным xsl-файлом

Другая система, над которой я работал, сделала еще один шаг вперед и в качестве отправленного ключа использовался идентификатор потока (он был для потокового видео), идентификатор пользователя и время суток, и если они совпадали, тогда поток был разрешен (с 1 минутное окно), чтобы начать.

Но все эти методы работают на знание порядка параметров ключа и скрытого ключа, отправляемого в одном или обоих направлениях, и md5 хэширует результирующую строку для видимого / передаваемого ключа.

...