Реализация аутентификации и авторизации на основе ролей в ASP.NET служба веб-API MVC и архитектура клиента MVC

Мне трудно решить подход при реализации сценария аутентификации/авторизации для моего проекта архитектуры Web API (Service) - MVC (client). Несмотря на то, что я реализовал пользовательскую аутентификацию на основе токенов в проекте Web API, мне сложно, где именно я должен реализовать авторизацию (в клиенте или в самом API).

Обзор Архитектуры :

  • Решение |
    | __ ASP.NET служба REST на основе веб-API (независимо размещенная на IIS в M/C 1)
    |
    / _ _ ASP.NET клиент на основе MVC (независимо размещенный на IIS в M/C 2, потребляющий службу REST)
    |
    / _ _ Клиентское приложение Smart phone (потребляющее услугу REST)

уже реализована аутентификация:

  • аутентификация на основе маркеров в веб-API (с использованием обработчика сообщений) - который генерирует маркер SHA1 для аутентифицированный пользователь, который должен быть частью каждого заголовка http-запроса для аутентификации.
    (Токен = имя пользователя + IP пользователя)

  • защищенный SSL HTTP-запрос. (Опять Же, Используя Обработчик Сообщений)

актуальные проблемы :

  1. на каком уровне должна быть реализована авторизация?
  2. как роль пользователя должна сохраняться в клиенте? Используя Cookies? или добавление сведений о роли в Маркер сам (который может добавить накладные расходы для API для расшифровки информации и дополнительных вызовов БД для получения разрешений, связанных с этой ролью)
  3. как маркер аутентификации должен сохраняться в сеансе клиента?
  4. поскольку мое приложение является приложением SPA MVC, каков наилучший способ включить токен аутентификации в качестве части каждого вызова AJAX, который я делаю в API?

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

8
asp.net asp.net-authorization asp.net-mvc asp.net-mvc-4 asp.net-web-api

2 ответов

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

чтобы ответить на ваши текущие проблемы:

1 вообще говоря, вы всегда хотите защитить свой Api с помощью аутентификации, так как это место, где вы получаете доступ к своим данным. Ваш клиент (приложение MVC / смартфон) должен авторизоваться, чтобы получить доступ к вашему Api.

2 & 3 Поскольку вы используете REST Api, я бы предложил держите Api без состояния, другими словами, Не храните информацию о сеансе. Просто включите необходимые данные роли в Маркер. Вы можете использовать, например,JSON Web Token.

4 Я всегда буду использовать заголовок authorization для отправки данных авторизации. В вашем DelegatingHandler (обратите внимание на разницу MessageHandler MVC, DelegatingHander HTTP) вы можете просто получить заголовок.

protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
 {
    var authorizationHeader = request.Headers.Authorization;
    // Your authorization logic.

    return base.SendAsync(request, cancellationToken);
 }

подробнее о том, как включить заголовок авторизации в вызове ajax см.:как использовать базовую аутентификацию с jQuery и AJAX?

дополнительная информация:

на вашем месте я бы также взглянул на сервер идентификации Thinktecture:https://github.com/thinktecture/Thinktecture.IdentityServer.v2

и, возможно, этот ответ об аутентификации службы REST также поможет вам: аутентификация службы REST

3

зачем создавать всю систему токенов (если вы не используете какую-то федеративную безопасность), у вас есть аутентификация форм и файлы cookie, как только файл cookie установлен и возвращен, браузер отправит файл cookie с любыми запросами AJAX, сделанными вашим SPA.

0