Как лучше всего пройти аутентификацию для веб-службы
У нас есть 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 и т. д. И т. Д.
Ответы 5
Если веб-сервис должен быть защищен, и я предполагаю, что это так, поскольку в настоящее время у вас есть заголовок Authentication, вам следует пересмотреть использование GET, а не SSL, по крайней мере, для части аутентификации. Как минимум, я бы отправил запрос авторизации через SSL в веб-службу / приложение. Если вы не хотите предоставлять аутентификацию для каждого запроса, вам нужно будет принять обратно (и сгенерировать в службе) файл cookie авторизации, который потребитель может использовать для последующих запросов.
Я бы избегал использования аутентификации в URL-адресе именно по той причине, по которой вы хотите поддерживать GET - если URL-адрес можно кэшировать, тогда учетные данные также будут кэшированы. Это нарушает безопасность веб-службы, поскольку любой может повторно использовать кэшированные учетные данные.
Используя API только GET, у меня был бы первый метод, который извлекает уникальный идентификатор сеанса.
Например: GET / api? Action = auth & username = user & password = hashedpassword Вернет токен с 16 символами, который вы храните на своей стороне, и вам потребуется этот уникальный токен для каждого последующего вызова.
Если бы API был выполнен на PHP, вы могли бы использовать его функциональные возможности PHP для обработки сеансов (у него есть тайм-аут / сборка мусора). Подобные функции есть в ASP.NET.
Он уязвим для повторной атаки (кто-то захватывает или угадывает идентификатор сеанса), но если вам нужно что-то простое, это правильный путь. Любой веб-сайт, не поддерживающий HTTPS, будет таким же уязвимым. Вы можете связать идентификатор сеанса с IP-адресом пользователя для дополнительной безопасности.
Если вы используете WCF, вы можете использовать встроенные механизмы безопасности. Если вы не хотите использовать стандартные фреймворки для обеспечения безопасности, вы, скорее всего, сделаете безопасность неизвестностью.
Я пробовал WCF на прототипе простой веб-службы. Я разработчик, ориентированный на код, и вся эта конфигурация xml меня отталкивает. К тому же я так и не узнал, как добавить кастомную авторизацию.
Если ваши клиенты находятся в одном домене, вы можете включить встроенную проверку подлинности Windows в своем приложении IIS. Теперь ваше приложение будет принимать только пользователей, прошедших проверку подлинности Windows. Добавьте свой собственный RoleProvider для более точной детализации на основе ролей.
Подобно ответу Томаса Эйда: вы можете использовать систему единого входа, такую как siteminder, для защиты URL-адреса. Вызывающий запрашивает необходимость включения токена, который обычно хранится в файле cookie, но может быть добавлен в строку запроса.
Любая платформа SSO или управления веб-сервисами намеренно затрудняет аутентификацию, если не использует SSL.
*) Кеширование должно происходить только на стороне клиента .. поэтому учетные данные должны быть такими же. ??? *) Не могли бы вы подробнее рассказать о cookie авторизации?