Как реализовать аутентификацию HMAC в RESTful WCF API
Мы создаем RESTful API с использованием WCF (в настоящее время .Net 3.5, но скоро перейдем на .Net 4). У нас есть функциональная структура, но в настоящее время она не обеспечена. Он должен быть доступен из приложений .Net, а также iOS, Android и веб-приложений.
Мы хотели бы использовать схему аутентификации HMAC, как описано здесь и здесь, но оба примера, кажется, разваливаются при описании того, как проверить хэш. Первый пример не дает возможности опишите ОбъектUserKeys (hashtable?) и во втором примере отсутствуют методыGetUserKey на стороне клиента и сервера.
Может ли кто-нибудь дать объяснение того, как "ключ пользователя"/токен генерируется/хранится/извлекается/используется в этих примерах, или предоставить лучший пример (с исходным кодом, если это возможно) того, как использовать авторизацию HMAC в RESTful WCF service?
Редактировать: После дополнительных исследований мы решили, что нам нужно больше "авторизация "техника, а не" аутентификация " техника (семантика?). Мы реализовали базовую авторизацию и защитили API за SSL. Базовая авторизация использует тот же заголовок "Authorization" из веб-запроса, что и схема аутентификации HMAC , но передает строку username:password, закодированную в Base64, а не токен. Это позволило нам выполнить пользовательскую проверку пользователя по нашей базе данных, чтобы определить, является ли он лицензируется и имеет соответствующие права безопасности для доступа к нужному методу API.
Мы, безусловно, готовы выслушать другие варианты о том, как выполнить пользовательскую проверку имени пользователя/пароля и другие методы защиты API.
2 ответа:
Получение пользовательского ключа-это всего лишь деталь реализации, которую вы можете сделать любым удобным вам способом, но на сервере он часто хранится в базе данных вместе с именем пользователя.
Основной подход очень прост.
Каким-то образом сервер и клиент обмениваются общим ключом для использования пользователем. Это можно сделать любым способом, включая отправку старомодного письма в стиле мертвого дерева. Довольно часто это просто пароль, который ввел пользователь.
- Когда клиент хочет отправить запрос он строит полный запрос, а затем с помощью секретного ключа вычисляет хэш по всему телу сообщения (и необязательно некоторые заголовки сообщений, если требуется)
Далее клиент добавляет вычисленный хэш и свое имя пользователя к сообщению в одном из заголовков и отправляет его в службу.- служба извлекает имя пользователя из заголовка сообщения и выполняет поиск этого пользователя в собственной базе данных в частном keu.
- Далее он вычисляет хэш над сообщением тело (и выбранные заголовки), используя ключ для генерации его хэша.
- если хэш, который посылает клиент, совпадает с хэшем, который вычисляет сервер, сервер знает, что сообщение было отправлено реальным клиентом и никоим образом не было изменено.
На самом деле единственная хитрость заключается в том, чтобы поделиться секретным ключом с пользователем и сохранить его в безопасности. Именно поэтому некоторые сервисы позволяют генерировать общие ключи с ограниченным сроком службы, так что вы можете дать ключ третьей стороне для временной работы на вашем компьютере. ради.