настраиваемая клиентом безопасность веб-сайта asp.net для детального контроля доступа к страницам и кнопкам

Question

У меня есть веб-сайт ASP.NET 2.0 [без ajax ... пока], который будет развернут в скомпилированном виде на нескольких сайтах клиентов. Как правило, сайт будет только интранет. Некоторые клиенты доверяют всем своим людям и не заботятся об ограничении доступа к функциям сайта и / или страницы, другие не доверяют никому и хотят, чтобы только определенные люди и / или группы могли просматривать определенные страницы, нажимать определенные кнопки и т. Д. и др.

Я мог бы сделать какое-то домашнее решение, возможно, получить разрешения на доступ из таблицы базы данных, но перед тем, как идти по этому пути, я подумал, что задам вопрос в SO: что является хорошим решением для этой ситуации? предпочтительно тот, которым можно полностью управлять в файле web.config и / или базе данных, поскольку перестройка веб-сайта невозможна (для клиента, и я не хочу делать это для них снова и снова). Интеграция с Active Directory будет бонусом, но не обязательным требованием (если только это не будет проще).

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

РЕДАКТИРОВАТЬ: раздел авторизации web.config, разрешающий / запрещающий доступ по роли и пользователю, хорош, но это только половина проблемы - другая половина контролирует доступ к отдельным методам (кнопкам и т. Д.) На каждой странице. Например, некоторые пользователи могут просматривать whatchamacallits, в то время как другим разрешено редактировать, создавать, удалять или отключать / включать их. Все эти кнопки / ссылки / действия находятся на странице просмотра ...

[в идеале я бы сделал отключенные кнопки невидимыми, но здесь это не важно]

РЕДАКТИРОВАТЬ: пока что есть хорошие предложения, но пока нет полного решения - все еще склоняюсь к решению на основе базы данных ...

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

РЕДАКТИРОВАТЬ: платформа Win2K / XP, Sql Server 2005, ASP.NET 2.0, не использует AJAX

Answer 1

Я думаю, что здесь вам нужно реализовать набор методов запроса разрешений либо в ваших бизнес-объектах, либо в вашем контроллере. Примеры: CanRead (), CanEdit (), CanDelete ()

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

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

Есть некоторый код, который использует эту модель в книге Роки Лхотки. Новая версия еще не в Google .

Answer 2

Хотя я никогда раньше не использовал это на практике и не могу спорить о его достоинствах, я знаю, что .NET обладает защитой кода на основе ролей, которая позволяет декларативно блокировать методы по роли или пользователю. Например:

[PrincipalPermissionAttribute(SecurityAction.Demand, Name = "MyUser", Role = "User")]
public static void PrivateInfo()
{   
    //Print secret data.
    Console.WriteLine("\n\nYou have access to the private data!");
}

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

Кроме того, вам нужно прочитать об интегрированной аутентификации Windows, чтобы получить возможность Active Directory.

Answer 3

Похоже, вы можете использовать элемент управления LoginView , который может отображать панели элементов управления только для определенных пользователей или ролей. Роли наиболее гибкие - если безопасность не требуется, поместите всех пользователей во все роли.

Использование в сочетании со стандартной безопасностью web.config (встроенные окна с активным каталогом или аутентификация на основе форм (схема сервера asp 2 Sql или ваша собственная).

<asp:LoginView id="LoginView1" runat="server">
                    <RoleGroups>
                        <asp:RoleGroup Roles="Admin">
                            <ContentTemplate>
                                <asp:LoginName id="LoginName2" runat="Server"></asp:LoginName>, you
                                are logged in as an administrator.
                            </ContentTemplate>
                        </asp:RoleGroup>
                        <asp:RoleGroup Roles="User">
                            <ContentTemplate>
                                <asp:Button id="Button1" runat="Server" OnClick="AllUserClick">
                            </ContentTemplate>
                        </asp:RoleGroup>
                    </RoleGroups>
                </asp:LoginView>

Answer 4

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

Я не знаю много о вашем приложении, но вы можете посмотреть тег авторизации в файле web.config:

<authorization>
    <!--  
        <deny users="?" />
        <allow     users="[comma separated list of users]"
                   roles="[comma separated list of roles]"/>
        <deny      users="[comma separated list of users]"
                   roles="[comma separated list of roles]"/>
    -->
</authorization>

Вы можете разделять файлы web.config для каждого каталога в вашем веб-приложении и вкладывать каталоги. Каждый файл web.config может иметь свой собственный раздел авторизации. Если вы поместите разные страницы в каждый каталог, вы сможете эффективно управлять безопасностью, разрешив определенную роль в каждом файле web.config и запретив все остальное. Затем вы можете управлять членами каждой роли в активном каталоге. Я считаю, что это эффективное решение, потому что оно эффективно использует инфраструктуру безопасности Microsoft Active Directory и ASP.NET без написания собственных пользовательских материалов, а если вы используете роли, можно переложить управление членством в ролях кому-то никогда не нужно трогать файл web.config, он просто должен знать, как использовать консоль управления AD.

Answer 5

Я думаю, мне нужно будет объединить авторизацию AD с таблицами «функции и разрешения» в базе данных, чтобы получить детальный контроль, который нам нужен -

• используйте файл web.config, чтобы разрешить посещать веб-сайт только авторизованным пользователям (через группы AD)
• создать таблицу «функций», в которой перечислены все страницы и функции, которые могут быть затронуты, например, кнопка редактирования страницы 1, кнопка удаления страницы 2, сетка подробностей страницы 3 и т. д.
• создать таблицу «разрешений», в которой указана функция, и группу AD, которой разрешено использовать эту функцию
• изменить страницы сайта, чтобы проверить разрешения функций при загрузке страницы (или, при необходимости, предварительно), чтобы отключить / скрыть запрещенные функции в зависимости от ситуации.

примеры:

• Администраторы могут использовать все функции сайта
• Разработчики могут использовать все функции сайта
• Менеджеры могут просматривать все страницы, но могут только добавлять и редактировать информацию, без удаления
• Супервизоры могут просматривать сводные данные по всем отделам, но просматривать и редактировать детали только для своего собственного отдела (для каждого отдела и отдела-администратора существует группа AD)
• Сотрудники могут просматривать детали только для своего отдела
• и т.д.

Окончательное решение сократило понятие «функция» до бинарного решения «использовать или не использовать» и добавило флаг «разрешающий / не разрешающий» к каждой функции. Это позволяет функциям, которые большинство может использовать, быть определенными как «разрешающие», и тогда в таблице разрешений нужно записывать только группы, которым не разрешено использовать эту функцию. Для функции, определенной как недопустимая, по умолчанию никто не может использовать эту функцию, и вам необходимо создать записи в таблице разрешений для групп, которым разрешено использовать эту функцию. Похоже, это дает лучшее из двух решений, так как уменьшает количество записей разрешений, необходимых для каждой функции.