Каков текущий стандарт для аутентификации запросов Http (REST, Xml поверх Http)? - PullRequest
2 голосов
/ 06 апреля 2010

Стандарт должен решать следующие задачи аутентификации, такие как: *

Атаки повторного воспроизведения Атаки «Человек посередине». Атаки по словарю Атаки с использованием грубой силы.и это одна возможность.Что еще более важно, кажется, что есть два наиболее распространенных подхода:

  1. Используйте apiKey, который кодируется аналогично AWS, но является параметром post для запроса
  2. Используйте Http AuthenticationHeader и используйтеподпись, аналогичная AWS.

Подпись обычно получается путем подписания отметки даты с зашифрованным общим секретом.Поэтому эта подпись передается либо как apiKey, либо в Http AuthenticationHeader.

Я хотел бы знать, как взвесить оба варианта сообщества, которые, возможно, использовали один или несколько, а также хотели бы изучить другие варианты, которые я не рассматриваю.Я бы также использовал HTTPS для защиты своих услуг.

Ответы [ 2 ]

2 голосов
/ 08 апреля 2010

«аутентификация» означает: докажи мне, что ты тот, кем говоришь

«кто вы» - это личность (человек, пользователь компьютера, программное обеспечение, сервер и т. Д.)

«идентичность» - это атрибут, уникальный для каждой сущности (здесь DBA скажет первичный ключ )

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

Он не беспокоится о безопасности канала, для этого предназначен уровень представления (т. Е. SSL), и для него требуется общий секрет между частями. «Общий секрет» означает, что обе части должны знать это, а никто другой не знает. Это подразумевает, что обе части доверяют друг другу в том, что не разглашают секрет или не принимают надлежащие меры в случае его раскрытия (например, изменение секрета).

HTTP как протокол не включает другие способы авторизации и оставляет его на других уровнях. Например, SSL может подтвердить идентичность двух сторон без раскрытия секрета с помощью инфраструктуры открытого ключа (сертификатов и центров сертификации).

В конце концов:

  • если вы можете поделиться секретом между сторонами, вы можете использовать HTTP-аутентификацию для аутентификации и SSL для защиты канала. Стороны могут безопасно обмениваться и хранить общий секрет

  • если вы не хотите делиться секретом, но стороны могут договориться об общей доверенной третьей стороне, вы можете говорить простым HTTP и использовать SSL как для защиты канала, так и для подтверждения личности одного или обоих стороны, использующие PKI (> сертификаты)

  • есть много других возможностей, но эти два являются наиболее стандартными, о которых я могу думать, и должны быть совместимы с большинством существующих программ / библиотек / библиотек HTTP / 10)

  • Системы домашнего приготовления, хотя и технически действительные, либо нарушат принятые стандарты, либо будут специальными (следовательно, нестандартными) системами, реализованными на прикладном уровне (для решения проблемы, которая должна решаться на другом уровне, например)

Нет способов доказать уникальность чего-либо без согласования общего секрета (и сохранения его в тайне) или согласия доверять кому-то другому, чтобы позаботиться об этой уникальности (PKI). Все остальное - просто детали реализации.

1 голос
/ 08 апреля 2010

Я не уверен, что есть один стандарт. Если есть, то, скорее всего, будет HTTP Auth (Basic или Digest). Оба из вышеперечисленных являются довольно плохими решениями.

AWS является хорошим примером того, как может работать «автоматическое» решение для проверки подлинности, однако, когда вы говорите о безопасности / аутентификации, roll-your-own обычно плохо идея, если вы не гуру безопасности / крипто.

На самом деле, я предпочитаю использовать только сертификаты на стороне клиента. Он заботится о процессе аутентификации и безопасности. Ключ API не нужен, потому что сам Cert идентифицирует пользователя клиента.

...