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

Question

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

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

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

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

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

Является ли это приемлемая и обычная практика?

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

Примечание: Я тоже не хочу, чтобы реализовать SSL, а также установки дополнительного программного обеспечения или плагинов в IIS, и т.д. и т.п.

Answer 1

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

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

Answer 2

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

Например: GET/апите действие = & аутентификация имени пользователя = пользователь & пароля = hashedpassword возвратит 16 CHARS маркера, который Вы храните на вашей стороне, и вы требуете этого уникального маркера для каждого последующего вызова.

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

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

Answer 3

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

Answer 4

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

Answer 5

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

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