Каков наилучший способ проверки подлинности для веб-службы

Question

У нас есть API веб-службы .NET. В настоящее время люди используют определение SOAP для использования API, потому что нам требуется аутентификация через пользовательский элемент Authentication в заголовке SOAP. Работает отлично. хорошо.

SOAP требует, чтобы запрос был POST. Мы хотим позволить пользователям использовать глагол GET (чтобы его можно было кэшировать).

Итак, что является лучшим способом предложить простой GET API (не обязательно должен быть веб-сервис!), Который также предлагает аутентификацию?

пример API-маршрута:

http://www.blah.com/api/Search?query=Foo

Это приемлемая и распространенная практика?

http://www.blah.com/api/Search?query=Foo&Key=<some guid>

ПРИМЕЧАНИЕ. Я также не хочу ни внедрять SSL, ни устанавливать дополнительное программное обеспечение или плагины в IIS и т. Д. И т. Д.

Answer 1

Если ваши клиенты находятся в одном домене, вы можете включить встроенную проверку подлинности Windows в своем приложении IIS. Ваше приложение теперь будет принимать только аутентифицированных пользователей Windows. Добавьте свой собственный RoleProvider для более точной гранулярности на основе ролей.

Answer 2

Если веб-служба должна быть защищена, и я предполагаю, что это так, поскольку у вас в настоящее время есть заголовок Authentication, то вам следует пересмотреть вопрос об использовании GET и не использовании SSL, по крайней мере, для проверки подлинности. Как минимум я бы отправил запрос авторизации через SSL к веб-сервису / приложению. Если вы не хотите предоставлять аутентификацию для каждого запроса, вам нужно будет принять обратно (и сгенерировать в сервисе) файл авторизации, который потребитель может использовать для последующих запросов.

Я бы не использовал аутентификацию в URL именно по той причине, по которой вы хотите поддерживать GET - если URL может быть кэширован, то также будут кэшированы учетные данные. Это нарушает безопасность веб-службы, поскольку любой может повторно использовать кэшированные учетные данные.

Answer 3

Аналогично ответу Томаса Эйде: вы можете использовать систему единого входа, например siteminder, для защиты URL. Вызывающий абонент должен включить токен, который обычно сохраняется в файле cookie, но может быть добавлен в строку запроса.

Любая SSO или платформа управления веб-сервисами намеренно затруднит аутентификацию, если не используется SSL.

Answer 4

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

Answer 5

Используя API только GET, у меня был бы первый метод, который выбирает уникальный идентификатор сессии.

Например: GET / api? Action = auth & username = user & password = hashedpassword Вернет токен в 16 символов, который вы храните на своей стороне, и вам потребуется этот уникальный токен для каждого последующего вызова.

Если бы API был создан на PHP, вы могли бы использовать его функцию обработки сеансов PHP для достижения этого (он имеет тайм-аут / сборщик мусора). В ASP.NET есть похожие функции.

Он уязвим для повторной атаки (кто-то захватывает или угадывает идентификатор сеанса), но если вы хотите что-то простое, это путь. Любой не-HTTPS веб-сайт будет уязвим таким же образом. Для дополнительной безопасности вы можете связать идентификатор сеанса с IP-адресом пользователя.