Как реализовать аутентификацию HMAC в API-интерфейсе RESTful WCF

Мы создаем RESTful API с использованием WCF (в настоящее время .Net 3.5, но скоро перейдем к .Net 4). У нас есть функциональная структура, но в настоящее время она не обеспечена. Он должен быть доступен из приложений .Net, а также для iOS, Android и веб-приложений.

Мы хотели бы использовать схему аутентификации HMAC, как описано здесь и здесь, но оба примера выглядят разваливаться при описании того, как проверить хэш. В первом примере не описывается объект UserKeys (хеш-таблица?), А во втором примере отсутствуют методы GetUserKey на стороне клиента и сервера.

Может ли кто-нибудь объяснить вам, как "Ключ пользователя" /токен генерируется/хранится/извлекается/используется в этих примерах или дает лучший пример (с возможным исходным кодом), как использовать авторизацию HMAC в RESTful Служба WCF?

Edit: После дополнительных исследований мы определили, что нам нужно больше "Authorization, а не Authentication" (семантика?). Мы внедрили базовую авторизацию и обеспечили API за SSL. Базовая авторизация использует тот же заголовок "Авторизация" из веб-запроса как схема проверки подлинности HMAC, но передает строку имени пользователя: пароль, закодированный в Base64 вместо токена. Это позволило нам настроить пользователя на соответствие нашей базе данных, чтобы определить, лицензирован ли пользователь и имеет ли соответствующие права доступа для доступа к требуемому методу API.

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

ОТВЕТЫ

Ответ 1

Извлечение ключа пользователя - это просто деталь реализации, который вы можете делать любым способом, но на сервере он часто хранится в базе данных вместе с именем пользователя.

Основной подход очень простой.

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

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