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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

Реализация для HMAC мы можем найти в

https://github.com/cuongle/WebAPI.Hmac