Разработка аутентификации для REST API

11

Я работаю над API для службы REST, которую собираюсь и производить, и потреблять. Я провел последние несколько дней, пытаясь понять, как правильно обращаться с аутентификацией, и думаю, что наконец-то что-то придумал.

Я придумаю это на основе следующих фактов о стеке приложений:

  1. Клиент и сервер находятся в .NET4 (часть клиента в профиле клиента)
  2. Сервер выставляется с использованием WCF REST
  3. Я действительно не хочу хранить имя пользователя и пароль в памяти приложения

С 3 я хотел использовать форму аутентификации токена, чтобы после проверки учетных данных сервером клиент получал токен для использования в остальной части приложения (это позволит мне делать другие вещи, такие как время ожидания пользователей, возможность плавного перемещения пользователей между веб-версиями и версиями для настольных компьютеров и т. д.). После того, как я выяснил, как сделать вызовы воспроизводимыми и защищенными от несанкционированного доступа, я придумал следующее:

  1. Прежде чем клиент попытается аутентифицироваться, он генерирует пару ключей Диффи-Хеллмана, используя ECDiffieHellmanCngкласс.
  2. Он передает открытую часть пары ключей по проводам вместе с именем пользователя и паролем (конечно, через HTTPS).
  3. Сервер аутентифицирует комбинацию имени пользователя и пароля, в случае успеха он затем делает следующее:
    1. Создает уникальный токен сеанса
    2. Генерирует свою собственную пару ключей DH и вычисляет общий секрет из открытого ключа, предоставленного клиентом
    3. Запоминает токен сеанса, общий секрет, пользователя и время «последнего действия» (используется для скользящего окна истечения) в своей базе данных
    4. Возвращает маркер сеанса, его открытый ключ DH и сообщение об успешной аутентификации
  4. Клиент берет ключ DH из ответа, вычисляет общий секрет и сохраняет токен и секрет в памяти.

С этого момента комбинация токен / секрет сеанса работает, как и большинство других API REST, с запросом, который снимают и ставят метки времени, а затем генерируют HMAC. Всякий раз, когда клиент выполняет действие против сервера, он проверяет пару токен / секрет и разрешает действие, если оно допустимо и не истекло, и обновляет последнюю запись действия в сеансе.

Я не вижу никаких явных недостатков, и, вероятно, слишком перегружен для этого, но мне нужно научиться делать это в какой-то момент. HMAC предотвращает повторные атаки, согласование DH помогает предотвратить MITM-атаки (я не могу представить себе работоспособную атаку на макушку между HMAC / DH).

Любые дыры, которые кто-нибудь может проткнуть в этом?

algorithms rest authentication Мэтт Зикер
источник
Я не вижу, как генерация ключей DH добавляет какую-либо безопасность по сравнению с простым использованием HTTPS везде и использованием простого старого файла cookie сеанса. При правильном использовании HTTPS уже защищает от атак «человек посередине» и повторных атак.
Ли Райан

Ответы:

5

Вместо того, чтобы придумывать свое собственное, вы должны рассмотреть возможность чтения API OpenAM и заимствовать его.

http://forgerock.com/openam.html

OpenAM Wiki особенно полезен

https://wikis.forgerock.org/confluence/display/openam/Home

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

С. Лотт
источник
Хм, это не выглядит плохо, одна вещь, которая мешает мне использовать это в этом случае: мы магазин .Net. Плюс, не так уж много об использовании этого с серверной стороной WCF. Единственная не спамовая ссылка, которую я смог найти в Google, указывает на использование WIF и WS-Federation.
Мэтт Зикер
1
@Matt Sieker: «Вам не нужно использовать их компоненты». Пожалуйста, прочитайте об их API вместо того, чтобы придумывать собственный.
С.Лотт
Ах, я думаю, я понимаю, что вы имеете в виду, требования обратного вызова. Это интересно, я мог бы рассмотреть это больше, если не для этого проекта, для будущих. Вместо того, чтобы выполнять аутентификацию как один атомарный блок, немного разбейте его, чтобы сервер мог контролировать то, что ему нужно от клиента ...
Мэтт Зикер
Первоначально мы развернули свою собственную, но затем перешли на OpenAM несколько лет назад в IG Group. Очень доволен продуктом с открытым исходным кодом.
Роберт Моршель
2

Я согласен на 100% с @ S.Lott, что ты не хочешь делать свои собственные. Я предлагаю рассмотреть другую альтернативу: Службу контроля доступа Windows Azure (ACS). ACS стоит денег, но он очень дешевый (10 000 транзакций за 0,01 доллара США) и обрабатывается большое количество инфраструктуры. WIF используется на клиенте.

Это также основанное на стандартах решение, основанное на претензиях, которое является модным. Проверьте эту статью об использовании WCF и REST и ACS вместе .

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

Удачи! -Билл

codingoutloud
источник