Как безопасно использовать конечную точку MVC WebAPI OData?

У меня есть конечная точка OData, определенная в ~/odata/, доступ к которой не требуется, если пользователь не прошел проверку подлинности (фактически, как вы защитите это для пользователей, не прошедших проверку подлинности).

Я устанавливаю аутентификацию на основе ролей по этому пути в web.config с помощью:

  <location path="odata">
    <system.web>
      <authorization>
        <allow roles="WaitConfirmation, etc...."/>
      </authorization>
    </system.web>
  </location>

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

Я использую EntityFramework для проверки пользователя, возврата объекта пользователя и уточнения сведений о членстве/ролях.

Является ли это стандартным методом, которому следует следовать, чтобы разрешить вызовы данных пользователей проходить через пути WebAPI, и если да, то как вы гарантируете, что любые запросы запросов WebAPI (помните, я использую OData) возвращают только данные, относящиеся к вошедшему в систему пользователю ?

Я только читал о «защите» сервисов OData с помощью декорирования методов контроллера (т.е. [Queryable(PageSize=10)]) для ограничения DOS-атак и т. д., но не о том, как гарантировать, что если общий параметр (т.е. UserID=[this logged in user id]) не включен , чтобы включить его во все запросы EF.


user-roles asp.net-web-api odata asp.net-mvc-4 roleprovider
person ElHaix    schedule 29.11.2013    source источник

Ответы (2)


arrow_upward
2
arrow_downward

На уровне API вы хотите внедрить схемы авторизации, позволяющие генерировать утверждения. Для веб-API вы можете использовать новое ПО промежуточного слоя OAuth 2.0 OWIN, если вы используете для этого веб-API 2.0. Хотя он не слишком хорошо документирован, он довольно прост в использовании.

Затем вы хотите реализовать уровень служб, который обрабатывает правила авторизации на основе утверждений об удостоверении, обращающемся к нему (например, роли или другие типы информации о утверждениях). Вы можете передать субъект утверждений или аналогичные объекты со своего уровня API на уровень служб, и если после авторизации вам потребуется дальнейший аудит на более низких уровнях вашего кода, вы всегда можете передать субъект утверждений в качестве своего «пользовательского контекста».

На уровне служб вы, как правило, захотите использовать подход, при котором у вас есть диспетчер авторизации или аналогичный, который перемещает оценку и принудительное выполнение логики авторизации в центральное место, в то же время определяя ваши правила авторизации декларативно — взгляните на эту статью для получения дополнительной информации. информация: http://visualstudiomagazine.com/Articles/2013/09/01/Going-Beyond-Usernames-and-Roles.aspx?Page=1

person mixja    schedule 03.01.2014
comment
Это еще одна статья, в которой показано, как это настроить: bitoftech.net/2014/06/01/ - person CodeGrue; 06.08.2014

arrow_upward
1
arrow_downward

Таким образом, главное препятствие, которое нужно преодолеть, — это думать, что все запросы WebAPI (с использованием синтаксиса OData) не имеют состояния. Конечно, в среде без гражданства это усложняет задачу.

Однако с конечной точкой WebAPI, защищенной с помощью web.config, требующей аутентифицированного (отслеживающего состояние) запроса, мы должны иметь возможность получить имя пользователя (или UserID или любое другое пользовательское свойство при использовании пользовательского поставщика членства) с помощью чего-то вроде var userId = ((CustomIdentity)HttpContext.Current.User.Identity).UserId.

Как только это будет установлено, нам нужно будет добавить что-то вроде «WHERE UserID = userId;» до отправки запроса:

        var unitOfWork = new Repository.UnitOfWork(_db);

        var users = options.ApplyTo(unitOfWork.Repository<MyTable>().Queryable
            .Include(w => w.NavigationProperty1)
            .Where(u => u.UserId == UserContext.Identity.UserId)
            .OrderBy(o => o.SomeProperty))
            .Cast<MyTable>().ToList();

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

person ElHaix    schedule 02.12.2013
comment
не было бы более разумно использовать фильтр запроса для предотвращения вызова действия на контроллере в случае, если текущий пользователь не имеет правильного членства в роли, вместо того, чтобы пытаться смешать логику аутентификации с бизнес-логикой? - person War; 04.08.2015
comment
@Wardy - Вы имеете в виду включение u.UserId? Я получаю часть фильтра запросов, но я также хочу убедиться, что фактические запросы зависят от пользователя. - person ElHaix; 20.08.2015