Небезопасность на уровне ролей?
Из readme документа в формате Word для RC1 (не индексированный Google)
Шаг
Постсборки Компилятора ASP.NET В настоящее время, ошибки в файле представления не обнаруживаются до времени выполнения. Чтобы позволить Вам обнаружить эти ошибки во время компиляции, ASP.NET, проекты MVC теперь включают свойство MvcBuildViews, которое отключено по умолчанию. Для включения этого свойства откройте файл проекта и установите свойство MvcBuildViews на истинный, как показано в следующем примере:
<Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<MvcBuildViews>true</MvcBuildViews>
</PropertyGroup>
Примечание , Активирующее эту опцию, добавляет немного служебные ко времени изготовления.
можно обновить проекты, которые были созданы с предыдущими выпусками MVC для включения проверки времени изготовления представлений путем выполнения следующих шагов:
- Открывают файл проекта в текстовом редакторе.
- Добавляют следующий элемент под самым верхним
<PropertyGroup>элемент:<MvcBuildViews>true</MvcBuildViews> - В конце файла проекта, не прокомментируйте
<Target Name="AfterBuild">элемент и измените его для соответствия следующему:
<Target Name="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(ProjectDir)\..\$(ProjectName)" />
</Target>
6 ответов
The way I've recently done something vaguely similar to this winds up looking like:
Person (person_id, name, etc)
Role (role_id, name [admin manager, stock manager, content manager, authorized reader, etc])
Technical_Manual (manual_id, title, etc)
Technical_Manual_Role (manual_id, person_id, role_id)
Additionally, in my system, roles are mostly just default permission bundles, and user permissions for specific actions (Read, Edit, Move, Delete, etc) can be made to vary up or down from the baseline for their role.
Проблема с принудительное приспособление всего к шаблону «ролей» - это логистика / объемы / рабочая нагрузка, чтобы поддерживать полный набор правил безопасности в случае, когда эти правила очень «детализированы».
По мелкому, я означают случай, когда в любом решении об авторизации присутствует множество потенциальных различающих факторов, и для каждого различающего фактора (скажем, «сумма кредита, запрашиваемого клиентом») существует потенциально большой диапазон «значений »(скажем, существует 25 различных диапазонов суммы кредита).
Допустим, есть три таких различающих фактора, каждый из которых имеет диапазон из семи возможных значений (7 различных диапазонов суммы кредита). Затем вы необходимо будет определить 7 * 7 * 7 = 343 роли. Затем для каждого отдельного пользователя вашей системы вам нужно будет назначить полное подмножество всех ролей, которые этот пользователь может выполнять. Если пользователь уполномочен принимать решение о предоставлении кредита заявка на сумму 50.000.000, то вполне вероятно (но опять же, не с полной уверенностью!), что он также уполномочен принимать решение по кредитной заявке на сумму 5.000.000.
Вот почему в моем проекте обеспечение - связанные функции ограничиваются идентификацией (идентификатор пользователя) и аутентификацией (сертификат пользователя). Нет никаких условий для авторизации.Они должны быть решены с помощью определенных пользователем ограничений.
Я знаю, что это может показаться немного запутанным, НО вы МОЖЕТЕ сделать что-то вроде этого:
Роли (role_id и т.д.)
Technical_Manual ( manual_id, accept_roles и т. д.) где accept_roles - это список с разделителями
Затем в вашей программе разделите список с разделителями. Я не говорю, что это НАИЛУЧШИЙ способ, но он будет РАБОТАТЬ. Хотя не знаю, подойдет ли он для военного применения :)
Вы можете использовать более основанный на утверждениях подход к авторизации.
Могут быть некоторые общие разрешения, которые может иметь или не иметь каждый пользователь (например, администратор), которые могут быть напрямую связаны с ролью. и мы будем использовать вашу таблицу для сопоставления конкретного пользователя с публикациями, на которые он имеет расширенные права, и создавать утверждения для этих записей.
поэтому, когда запрашивается авторизация пользователя, вы получаете набор утверждений, некоторые из которых являются высокоуровневыми производные от ролей, и некоторые специфические для публикации, полученные из ваших таблиц.
Комментарий к ответу Хаоса:
Мне пришло в голову, что роли «системного уровня» могли бы соответствовать той же схеме, если бы manual_id для таких вещей можно было бы установить равным null или некоторым магическим значением. Да, я знаю, некоторые люди очень не любят нули, но здесь это работает. Тогда была бы одна таблица «безопасности», и все было бы чисто.
У меня действительно было много проблем с тремя полями менеджера. У нас было несколько запросов, таких как «За какие книги отвечает Боб?», Которые требовали запроса с большим ИЛИ для всех трех полей. Это означало, что нам нужно три индекса. Позже я понял, что лучше было бы вынести это в отдельную таблицу. Но бросая авторизованных читателей в ту же таблицу ... многое убирается. Добавьте сюда вещи системного уровня и ... Мне это нравится. Легко спросить: «Какие права у Мэри Джонс?» а также «Кто имеет права на руководство по авионике F-15?», «Кто все наши менеджеры по техническому контенту?» и т. д.
Просто хотел добавить больше с концептуальной точки зрения. Несмотря на то, что RBAC (контроль доступа на основе ролей), кажется, в моде, существует множество моделей, таких как DAC, MAC, которые были доступны для решения проблемы контроля доступа в течение более длительного времени (RBAC фактически был формализован где-то около 1995 года, в то время как другие модель существует гораздо дольше и используется военными). Как вы объяснили требования, я вижу, что используется несколько моделей
- RBAC - используется в случае "системных ролей", о которых вы говорили.
- Управление доступом на основе атрибутов / политик - используется для всех связанных с руководством шт.
- MAC - используется для управления доступом к руководствам на базовом уровне, то есть для каждого руководства и пользователя есть связанный уровень чувствительности, и они должны соответствовать на основе определенных критериев, чтобы иметь возможность доступа.
Эти модели могут быть выражены с использованием стандартов, таких как XACML (и оценены во время выполнения с использованием реализаций механизма политик), которые могут описывать политику. Например, в вашем случае политика будет выглядеть примерно так:
(На основе атрибута)
Разрешить «всем» «редактировать» «руководство», если userId = manual.technical_content_manager
Разрешить «всем» «отправлять» "" manual "if userId = manual.stock_manager
(RBAC)
Разрешить HelpDesk" просматривать "" ручную информацию "," manual "
Разрешить" администратору "" просматривать "," редактировать " , "ship" "manual"
(MAC)
Разрешить "всем" "просматривать" "manual", если userId.level> = manual.level
На основе модели политики выше,