Аутентификация пользователя для мобильных клиентов в сервисе RESTful WCF 4

Question

Я пытаюсь разработать веб-сервис, который будет использоваться мобильными клиентами (на данный момент, iOS-клиентами), я прочитал, что сервисы RESTful намного легче, чем сервисы SOAP, поэтому я хотел бы попробовать свои силы в этом .

Большинство методов требуют аутентификации, но я не уверен, как с этим справиться, так как я читаю, что REST должен быть без состояния, поэтому как я могу проверить пользователя, получающего доступ к сервису из iOS, а затем использовать эту аутентификацию для проверки успешности вызовы других веб-методов?

Примечание: я буду использовать WebFttp: WCF 4 на IIS.

Спасибо!

Answer 1

Для этого существует ряд достаточно устоявшихся шаблонов.

• Самый простой способ заключается в предоставлении имени пользователя: пароля в качестве заголовка авторизации или части запроса (строка запроса / данные формы).Это потребует от вас аутентификации / авторизации пользователя при каждом вызове.Возможно, это не идеально для вас, но если вы используете WebHttp (если вы не имели в виду это, я бы серьезно посмотрел на WCF Web Api ), было бы довольно легко создатьHttpModule или что-то в стеке канала WCF для перехвата вызовов и аутентификации пользователя.
• Очень распространенным способом является предоставление конечной точки, которая принимает user: password и генерирует токен API.Затем пользователь берет этот токен API и использует его для аутентификации последующих вызовов.Этим токеном может быть что угодно, от слабо зашифрованных данных до хеша, состоящего из общего секретного ключа, HTTP-глагола, запрошенного ресурса и т. Д. Вы найдете несколько примеров этого, если зайдете в Google «Аутентификация HMAC». Схемы аутентификации Azure являются примером действительно гранулированного токена.Хорошая вещь в этом подходе состоит в том, что у вас есть одна конечная точка, связанная с аутентификацией и построением токенов, а ваши другие конечные точки просто должны знать, как проверять хэш или дешифровать токен;хорошее разделение проблем.
• OAuth / OAuth2 являются стандартом де-факто, если вы ожидаете, что потребитель вашего API будет сторонним приложением.

Answer 2

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

Если вы работаете в IIS, я выполнил это перед использованиемHttpModule для проверки всех входящих запросов на действительный токен.Если его нет, модуль просто завершает запрос с помощью кода статуса 401 Unauthorized Http.

EDIT:

Если вы хотите выполнить более детальную авторизацию для каждогоЯ бы посоветовал использовать собственную политику авторизации.Проверьте http://msdn.microsoft.com/en-us/library/ms731181.aspx для более подробной информации.