Членство / Авторизация через службу REST

Question

Я занимаюсь созданием службы WCF REST для существующего приложения asp.net, которое будет использоваться различными клиентами, включая Windows Phone 7, Android, приложения для iPhone и т. Д.

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

Приложение asp.net использует провайдера Membership для обеспечения аутентификации и авторизации, и мне удобно использовать этот API из службы REST.

Как защитить службу REST таким образом, чтобы при первом вызове выполнялась аутентификация (с передачей имени пользователя и пароля), а при последующих вызовах выяснялось, кто вошел в систему. Я предполагаю, что метод authenticate должен будет передать некоторый токен, который будет использоваться в последующих вызовах, идентифицирующих вызывающего. Достаточно ли это безопасно, поскольку весь сайт / служба работает по протоколу SSL?

Любые предложения приветствуются.

Answer 1

Более спокойной схемой аутентификации является использование HTTP-аутентификации, например, Основной или Дайджест. Так как ваш сервис работает по SSL, Basic должно быть достаточно. Токены аутентификации (логин / пароль) отправляются с каждым запросом, поэтому сервис может быть без сохранения состояния. Каждая клиентская библиотека, о которой я знаю, может работать с базовой аутентификацией.

Answer 2

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

Так что, если у вас есть время и знания, а ваши клиенты умны, лучше использовать маркерный подход. В противном случае для SSL достаточно базовой аутентификации.

Answer 3

Я видел пример из последнего набора инструментов Windows Azure для WP7, который может оказаться полезным для вас.В основном он использует поставщика членства, регистрирует пользователя (в первый раз, когда человек устанавливает приложение), а затем генерирует билет.Затем он шифрует этот билет и отправляет его обратно как токен, который затем сохраняется на телефоне в изолированном хранилище.Срок действия билета устанавливается равным int.MaxValue, чтобы токен оставался исправным в течение длительного периода времени.

Теперь этот токен передается веб-службам в заголовке авторизации, где он дешифруется,личность пользователя проверяется, а затем выполняется вызов веб-службы.

Надеясь, что это поможет.Я пытаюсь решить подобный сценарий и, поверьте мне, не так уж много того, что указывает нам правильное направление ... что довольно печально, если вы спросите меня.