Пользовательская безопасность в ASP.NET MVC для приложений (не для массового рынка)

Question

Я создаю приложение SaaS и у меня есть некоторые проблемы, связанные с авторизацией и ASP.NET MVC. У меня есть предыдущий вопрос , и это своего рода реплика из комментариев. Мне нужно обеспечить некоторую детальную безопасность (например, множество разрешений) для каждого пользователя. Я понимаю, что любая дискреционная система может быть смоделирована как система ролей, просто создавая больше ролей. Но это гораздо больше ролей, чем я хочу иметь дело. Я не думаю, что роли будут работать для меня и хотел бы работать больше на уровне разрешений.

Мне известен стандартный ответ на любой вопрос, касающийся ASP.NET, и авторизация заключается в создании всех пользователей вашего приложения в качестве пользователей Windows и реализации поставщика членства ASP.NET. Одна проблема, я не собираюсь создавать пользователей Windows. У меня вопрос: можно ли сделать стандартные ASP.NET MVC AuthorizeAttribute и AuthorizeCore в соответствии с моделью разрешений?

Кроме того, очевидно, что стимулом здесь является то, что ASP.NET MVC Caching нарушит пользовательскую реализацию безопасности. Очевидно, я не хочу, чтобы мои страницы работали медленно, но я не уверен, что вообще хочу это кэширование. Я создаю бизнес-приложение; кэширование всего действительно уместно? Кажется, что кеширование только усложнит проблемы параллелизма, чем они уже есть. Например, если я кеширую все свои страницы с информацией о клиентах, включая страницы редактирования, не буду ли я побеждать какие-либо элементы управления параллелизмом, которые у меня были бы (например, проверка меток времени)?

Answer 1

На вашем месте я бы не создавал пользователей как пользователей Windows, а скорее сохранял бы их в базе данных SQL. Теперь у вас есть полный контроль над тем, как вы хотите связать свои потребности в безопасности с вашими пользователями.

Как только вы это сделаете, вы сможете создать собственный фильтр безопасности, создав класс, который реализует IAuthorizationFilter. Таким образом, у вас есть элемент управления, который вы хотите сделать, какую бы проверку вы ни хотели, на основе ролей, на основе разрешений, на основе дня недели и т. Д.

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

Answer 2

Вам не нужно создавать пользователей Windows для использования поставщика членства ASP.NET, он использует таблицы SQL для хранения объектов членства. Да, вы можете использовать атрибут Authorize с поставщиком членства, например, на странице, которую могут редактировать только «администраторы», вы будете использовать атрибут authorize следующим образом:

[Авторизоваться (Users = "Администратор")]

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

Надеюсь, это поможет.

Answer 3

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

Редактировать страницы, как правило, не следует кэшировать, так как они не будут загружаться несколько раз с одними и теми же данными в течение срока службы кэша. Мой мыслительный процесс заключается в том, что в MVC достаточно просто добавить кеширование, чтобы я сначала его построил, а затем проверил производительность, чтобы убедиться, что это даже необходимый шаг. (Помните, что если вы не просматриваете большое количество клиентских подключений, то, как правило, более экономичным является создание чуть менее производительного кода и усиление аппаратного обеспечения сервера.