Как защитить действия контроллера в приложении MVC, которое не содержит данные db или пользователя?

Question

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

Мое положение состоит в том, что я являюсь частью распределенного приложения. Моя часть - это приложение MVC5, которое в основном состоит из нескольких контроллеров, которые возвращают одностраничные приложения. Итак, нажмите контроллер A и верните одностраничное приложение A. Хит-контроллер B и получите одностраничное приложение B. И т.д. Это приложение не содержит базы данных или пользовательских данных. Некоторые другие приложения на совершенно другом сайте/сервере. Я хочу спросить, что другое приложение, если пользователь действителен, или попросить пользователей напрямую обратиться к другому приложению и разрешить доступ только к моим приложениям, если ответ да. Поэтому, по сути, я хочу защитить свои контроллеры на основе слова удаленного приложения, которое содержит открытую api для проверки имени пользователя/пользователя.

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

маркер

• Доступ должен быть сгенерирован
• Получение маркер доступа не является частью контроллера счета, это часть Owin промежуточного
• Маркер доступа будет отправлен вместе с просьбы о моих действиях
регулятора,
• моего контроллера действия, декорированном с [Authorize] атрибутом, будет разбирать маркер и сделать правильную вещь

Вопросов:

• Q1: Должен ли я генерировать токен или другое приложение - одно с данными db и пользователем?
• Q2: Мои контроллеры ничего не знают о пользователях. Эти данные находятся в другом приложении. Что конкретно контролируют контроллеры под капотом, чтобы делать правильные вещи? По сути, что конкретно говорит им: «Да, этот запрос в порядке. Верните представление».
• Q3: Я снова начал свой проект с помощью стандартного шаблона проекта MVC5, который поставляется с VS2015, потому что я решил, что буду обращаться с пользователями/логином и т. Д. Это оказалось не так. Должен ли я вернуться и повторить этот проект с нуля, потому что этот шаблон не соответствует этому требованию или я могу сделать некоторые операции на нем и продолжить? Например, я не знаю, имеет ли этот шаблон все материалы OWIN, которые мне нужны, или, может быть, слишком много лишнего мусора (раздутый контроллер учетных записей, Entity Framework и т. Д.), Которые легко преобразуются/поддерживаются.
• Q4: Является ли авторизация токена здесь? Существует ли более простой способ запретить пользователям неавторизованных пользователей доступ к моим действиям контроллера, что имеет большее значение с учетом характера проекта?

Любое понимание будет оценено по достоинству.

Обновление: Что я имел в виду в Q2, было, пожалуй, проще, как работает [Авторизоваться]? Детали? Я предполагаю, что должен сказать, как работать. Например, глупый пример для иллюстрации. Если бы я хотел сказать контроллеру, украшенному [Авторизовать], чтобы кто-нибудь из тех, у кого есть имя пользователя «fred», как и где я это сделаю? Я не столько ищу код. Я думаю концептуально. Мое приложение должно знать что-то о токенах, которые другое приложение (аутентификационное приложение) генерирует. В общих чертах, что бы я добавил в мое приложение MVC, чтобы рассказать ему, как декодировать эти токены? Где его добавить? Есть ли одно стандартное место?

Answer 1

Кажется, вам нужно реализовать процесс OpenID/OAuth2.

Таким образом, ваши приложения смогут использовать единый вход (SSO) для всех ваших приложений, и все, что вам нужно сделать, это настроить ваше приложение MVC5 как клиента OpenID/OAuth2.

Загляните в Azure AD B2C, который идеально подходит для этого (сейчас я реализую это сейчас для 3 проектов, над которыми я работаю).

https://www.asp.net/mvc/overview/security/create-an-aspnet-mvc-5-app-with-facebook-and-google-oauth2-and-openid-sign-on

https://azure.microsoft.com/en-us/services/active-directory-b2c/

https://identityserver.io/

Answer 2

Я думаю, что вы на правильном пути, и правы шаги, которые вы упомянули. Я отвечу на ваши вопросы, исходя из того, что я понимаю:

Q1. Другое приложение - это тот, который должен авторизовать и генерировать токен (независимо от того, какой механизм авторизации он использует), и вы должны получить этот токен перед показом своих просмотров. Поскольку данные поступают из другого приложения, они должны предоставить вашим контроллерам доступ к их данным. Вот почему вам нужно спросить другое приложение для токена/авторизации. При наличии действительного токена, полученного из другого приложения, ваше приложение может отправлять действительные и авторизированные запросы своим данным.

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

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

q4. Это то, что нужно сделать другому приложению. Насколько я понимаю, я думаю, что вы добавляете веб-API в существующую систему, поэтому я думаю, вам нужно знать, как вы можете интегрироваться с другим приложением. Они должны иметь четкие API, которые являются общедоступными для вас, чтобы получить доступ к их функциям и данным.

Поскольку вы не упомянули, является ли это другое приложение чем-то вроде безопасного корпоративного решения или API Google (имеется общедоступный API), было бы сложно точно сказать, чего вы можете ожидать от другого приложения.

Я думаю, что вам нужно попробовать JSON web tokens (JWT)
Я не использовал его сам, хотя. stormpath.com/blog/token-auth-spa - Это полезно для аутентификации запроса вашего контроллера. Вот такой же вопрос, как у вас есть (я думаю), и как JWT мог решить ее How to use JWT in MVC application for authentication and authorization? и https://www.codeproject.com/Articles/876870/Implement-OAuth-JSON-Web-Tokens-Authentication-in

---

Вы можете переопределить AuthorizeAttribute так: https://msdn.microsoft.com/en-us/library/ee707357(v=vs.91).aspx. Ваша авторизационная логика проверки того, какой механизм токенов/авторизаций вы решите добавить в этот новый фильтр действий. Затем добавьте этот новый атрибут в свои действия.Так что если ваш атрибут пользовательские разрешения при переопределении выглядит так:

public class RestrictAccessToAssignedManagers : AuthorizationAttribute 

Тогда ваши действия будут иметь украшение атрибута, как это:

[RestrictAccessToAssignedManagers] 
public ActionResult ShowallAssignees(int id) 

нашел хорошую статью, которая также может быть помощь - https://blogs.msdn.microsoft.com/martinkearn/2015/03/25/securing-and-securely-calling-web-api-and-authorize/

Answer 3

Мой ответ на ваш вопрос будет основываться на:

I ва nt спросить, что другое приложение, если пользователь имеет силу или имеет пользователей , запрашивает другое приложение непосредственно и разрешает доступ к моим представлениям приложения, если да. Поэтому, по сути, я хочу защитить мои контроллеры на основе слова удаленного приложения, которое содержит разоблаченный api для проверки имени пользователя/пользователя.

Да, к моему скромному мнению, подход, основанный на токенах на основе oauth, является излишним для ваших нужд. Иногда лучше всего держать вещи (и глупо?). Поскольку вы являетесь частью распределенного приложения, я полагаю, вы можете (буквально) поговорить с командой, отвечающей за «другое приложение/веб-сайт», откуда будут поступать запросы, которые попадают в ваши контроллеры.

Итак, я пропущу ваши вопросы 1, 2, 3 и 4, которые ориентированы на основе маркеров OAuth подхода, и предложить несколько иного, «упрощенный» и быстрый подход, который заключается в следующем:

Для большей наглядности давайте назовем другое приложение «RemoteApp» и ваше приложение «MyApp», или «Другая команда» и «Вы», соответственно.

-Там 1: вы (MyApp) обмениваете симметричный секретный ключ с другой командой (RemoteApp);

-Step 2: MyApp и RemoteApp соглашаются с алгоритмом, который будет использоваться для хеш-данных, которые будут отправлены в MyApp, когда пользователь из RemoteApp запрашивает страницу на MyApp. Здесь вы можете, например, использовать алгоритмы MD5 или SHA256, которые хорошо документированы в MSDN и довольно легко реализуются на C#;

Шаг 3: MyApp сообщает RemoteApp, что его необходимо сделать частью опубликованных данных для проверки/аутентификации запроса.

Пример: Шаг 1: BSRabEhs54H12Czrq5Mn = (просто случайный секретный ключ. Вы можете выбрать/создать свой собственный);

Шаг 2: MD5 (это алгоритм, выбранный 2 сторон)

Шаг 3: Опубликованные данные запроса может включать в себя (по крайней мере, 3 - 4 параметров или полей формы, а также контрольная сумма): - UserName + RemoteApp полное доменное имя + someOther blabla data1 + someOther blabla data2 + контрольная сумма

Вышеуказанная информация будет объединена без пробела.Например, давайте предположим, что:

UserName = fanthom 
RemoteApp fully-qualified domain name = www.remote.com 
someOther blabla data1 = myControllerName 
someOther blabla data2 = myActionName 

Контрольная сумма будет генерироваться следующим образом (прототип функции):

generateMD5(string input, string secretKey) 

, который будет вызываться со следующими аргументами:

string checkSum = generateMD5("fanthomwww.remote.commyControllerNamemyActionName", "BSRabEhs54H12Czrq5Mn=") 

Обратите внимание, что в первом аргументе указанные выше 4 параметра были объединены без пробела, а второй аргумент - секретный симметричный ключ.

выше будет выход (фактическая контрольная сумма MD5):

checkSum = "ab84234a75430176cd6252d8e5d58137" 

Затем RemoteApp просто должен включать контрольную сумму в качестве дополнительного параметра или полей формы.

Наконец, после получения запроса MyApp просто должен будет выполнить ту же операцию и проверить checkSum. То есть, конкатенировать Request.Form ["UserName"] + Request.Form ["Полное имя домена RemoteApp"] + ["someOther blabla data1"] + ["someOther blabla data2"], , затем использовать функцию md5 с помощью секретный ключ, чтобы проверить, соответствует ли полученная контрольная сумма той, которая была отправлена ​​в запросе, поступающем с RemoteApp.

Если они совпадают, запрос является подлинным. В противном случае отклоните запрос!

Это все люди!

Answer 4

Итак, ваше приложение является общедоступным? Я не могу точно сказать из вашего описания.

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

Теперь вот где я запутался. Если это внешний клиент, который обращается к различным частям вашего распределенного приложения, у ВСЕХ частей есть эта проблема.

Как правило, клиент аутентифицируется в одном месте (например, написано командой A), любые другие последующие запросы на просмотр также должны быть проверены (HTTP без установления соединения/без гражданства), включая другие, выполненные командой A? Таким образом, ваша проблема уже будет решена (потому что это будет проблемой для всех, и они бы что-то сделали с помощью службы проверки подлинности cookie +, использовали ту же проверку ...)?

Это заставляет меня думать, что запросы на просмотр являются внутренними, а не обращенными к клиенту, и в этом случае ... почему это так важно?

Если вы можете уточнить свой сценарий вокруг того, что просит Вам нужно авторизироваться ...

Answer 5

вы на правильном пути. Но вместо того, чтобы вы использовали стороннюю компанию OAUTH и OpenIDConnect, которая делает тяжелую работу.Одним из таких инструментов является IdentityServer

https://identityserver.github.io/Documentation/docsv2/

Теперь, отвечая на ваш вопрос с IdentityServer точки зрения

необходим маркер доступа к генерироваться - истинный

Получение маркера доступа не является частью контроллера учетной записи, это часть промежуточного ПО OWIN - да, для лучшего дизайна

Токен доступа будет отправлен вместе с запросами на действия моего координатора. Мои действия с контроллером, украшенные атрибутом [Авторизовать], будут анализировать токен и делать правильную вещь. - Да как часть заголовка ответа

Вопросы: Вопрос 1: Должен ли я генерировать токен, или должно ли другое приложение - с данными db и пользователя? Сервер идентификации будет генерировать маркер, который вы запросили.

Q2: Мои контроллеры ничего не знают о пользователях. Эти данные находятся в другом приложении. Что конкретно контролируют контроллеры под капотом, чтобы делать правильные вещи? По сути, что конкретно говорит им: «да, этот запрос в порядке. Верните представление. - обычно токен отправляется обратно на идентификационный сервер, чтобы проверить его достоверность и получить access_token, который будет проверять, имеет ли пользователь права доступа. а не атрибут [Авторизовать] будет выдавать сообщение об ошибке и возвращать

Q3: Я начал свой проект некоторое время назад, используя стандартный шаблон проекта MVC5, который поставляется с VS2015, потому что я решил, что буду обрабатывать пользователей/логин и т. д. Это оказалось это не так. Должен ли я вернуться и переделать этот проект с нуля, потому что этот шаблон не соответствует этому требованию или я могу сделать некоторые операции на нем и продолжить? Например, я не знаю, у шаблона есть все вещи OWIN, которые мне нужны, или, возможно, слишком много лишнего мусора (раздутый контроллер аккаунта, Entity Framework и т. д.), чтобы быть легко трансформировали/поддерживается. - Да, вы можете удалить лишние вещи

Q4: Является ли авторизация токена здесь? Существует ли более простой способ запретить пользователям неавторизованных пользователей доступ к моим действиям контроллера, что имеет большее значение с учетом характера проекта? - Это не убийство. Это правильная вещь для вашего сценария