Одностраничное приложение с использованием контроллера — как защитить с помощью ASP.NET Identity?

У меня есть одностраничное приложение, которое использует стандартный контроллер (не ApiController) для получения всех представлений HTML, что выполняется через ajax. Однако WebApi используется с помощью breezejs, чтобы клиент мог общаться с серверной базой данных. Я реализую безопасность идентификации ASP.NET. Следует ли мне использовать аутентификацию файлов cookie MVC или токен носителя? Мне нужно решение, чтобы проиллюстрировать отдельную страницу входа в систему, и мне нужно чистое перенаправление на стороне сервера.


person user210757    schedule 08.11.2013    source источник
comment
Если ваш WebAPI обеспечивает безопасность, то чего вы пытаетесь достичь с помощью контроллера MVC? Вы хотите обезопасить свои представления от открытия?   -  person PW Kad    schedule 11.11.2013
comment
Да, я хочу обезопасить сайт (просмотры) и веб-API.   -  person user210757    schedule 11.11.2013
comment
Как вы входите в систему?   -  person PW Kad    schedule 11.11.2013
comment
Отдельные учетные записи пользователей, использующие базу данных удостоверений ASP.NET, но в будущем будут проходить аутентификацию в Yahoo, Facebook и т. д.   -  person user210757    schedule 11.11.2013
comment
Хорошо, я добавил ответ, который, я думаю, должен вам помочь. Если это не относится к вашему вопросу напрямую, пожалуйста, дайте мне знать. Я также обновил ваш вопрос, включив в него тег Breeze.js на случай, если кто-то еще ищет аналогичный ответ в будущем.   -  person PW Kad    schedule 11.11.2013


Ответы (1)


Отказ от ответственности

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

Предположения

  1. Ваш проект веб-API имеет собственную аутентификацию и не взаимодействует с проектом MVC, чтобы получить пользователя сеанса или что-то еще.
  2. Ваши контроллеры ASP.NET MVC находятся в проекте, использующем проверку подлинности с помощью форм и сохраняющем пользователя в файле cookie сеанса.
  3. Когда я ссылаюсь на MVC ниже, вы понимаете, что это ссылка на ASP.NET MVC.

Рекомендация

Я бы хотел, чтобы ваш проект MVC использовал OAuth для аутентификации и сохранял пользователя в файле cookie в сеансе, который вы можете установить и получить. Затем действия вашего контроллера, обслуживающие представления, можно украсить атрибутом Authorize. Это перенаправит пользователей на страницу входа, когда они попытаются получить доступ к представлению, к которому им не разрешено (если это настроено в вашем файле web.config).

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

Когда ваш пользователь успешно аутентифицирован в вашем проекте MVC, сделайте запрос к веб-API для открытого метода входа в систему. Это выполнит логический тест, а затем либо сохранит пользователя в БД с каким-либо токеном сеанса, либо автоматически запишет пользователя в БД.

Теперь ваш пользователь, который хранится в сеансе в вашем проекте MVC, вы можете передать его клиенту и добавить его к вызовам Breeze к вашему веб-API и использовать его для аутентификации. Вам нужно будет явно указать, как долго этот токен и тому подобное, но довольно легко добавить это к вызову Breeze.js следующим образом:

 var query = breeze.EntityQuery.from('myService').withParameters({'tokenId': thisTokenId});

Теперь ваши запросы будут попадать в API с параметром tokenId, который он может использовать для аутентификации.

Изменить

Если вы хотите настроить свой проект ASP.NET MVC для использования OAuth, вы можете перейти по этой ссылке -

http://www.asp.net/mvc/tutorials/security/using-oauth-providers-with-mvc

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

person PW Kad    schedule 11.11.2013
comment
Когда вы говорите настроить страницу входа в конфигурацию, вы имеете в виду ‹режим аутентификации=Forms› ‹forms loginUrl=~/Account/Login timeout=30 name=.ACMFORMSAUTH /› ‹/authentication›? Потому что я не думаю, что мне нужна проверка подлинности с помощью форм. Пример нового удостоверения MVC делает следующее: И пример SPA использует другую форму безопасности — - person user210757; 11.11.2013
comment
app.UseCookieAuthentication (новые CookieAuthenticationOptions()); app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie); app.UseOAuthBearerTokens(OAuthOptions); Итак, я подумал, что мне нужно использовать UseOAuthBearerTokens для аутентификации в обоих случаях. Я думаю, что ваши предложения все еще верны, мне просто нужно понять перенаправление страницы входа и то, как сторона веб-API (бриз) будет правильно аутентифицироваться - person user210757; 11.11.2013
comment
Добавлено редактирование в нижней части ответа - проверка подлинности с помощью форм просто означает, что вы предоставляете форму, которую пользователь может использовать для входа в систему, что в данном случае, вероятно, является страницей, позволяющей анонимным пользователям попасть на нее. - person PW Kad; 11.11.2013
comment
PW Мне могут понадобиться некоторые пояснения - я не понимаю передачу tokenId в breezejs. Что ветер делает с токеном? Мне также не совсем понятен запрос к веб-API для открытого метода входа в систему. Это выполнит логический тест, а затем либо сохранит пользователя в БД с каким-либо токеном сеанса, либо автоматически запишет пользователя в БД. Итак, вы говорите, что у вас должен быть какой-то внутренний код для проверки токена при каждом вызове? Разве простое использование аутентификации токена носителя для обоих не будет делать то же самое без необходимости делать это? - person user210757; 13.11.2013