MVC5 на основе утверждений на основе утверждений - подходящие элементы претензии

Question

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

Например, существует несколько мелких булевых разрешений для разных областей сайта, которые я не уверен, где их поставить. например - CanAccessX, CanAccessY, CanAccessZ и т.д ..

Может кто-нибудь сказать мне, если эти виды вещей хороши для превращения требований или они принадлежат где-то еще?

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

Спасибо.

Answer 1

Включение разрешений в претензии обычно является хорошей идеей, если это соответствует требованиям приложения. Одним из преимуществ защиты на основе требований является развязка между метаданными пользователя (имя, роль, возраст, разрешение и т. Д.) И требования безопасности приложений. Если, например, для некоторого «действия» требуется, чтобы пользователь имел определенный возраст, необходима простая проверка HasClaim(c => c.Type == Age && c.Value >= 18). И если для этого требуется простое разрешение, почему бы просто не проверить HasClaim(CanAccessX)?

Многие приложения (неправильные) используют группы/роли, такие как «CanAccessX»/«CanReadY»/«CanWriteZ» для реализации менее сложного (= лучшего) механизма безопасности. С претензиями эта концепция становится как-то естественной.

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

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

Обратите внимания, уже есть .NET механизмы для обработки этого печенья материала надежно: для классиков (текущие) IIS приложений, которые вы можете использовать Session Authentication Module, для современных (будущего) приложения Owin вы можете использовать Cookie Authentication Middleware.