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

Я предпочитаю предоставлять права доступа группам 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.

Хотя я никогда раньше не использовал это на практике и не могу оспаривать его достоинства, я знаю, что .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.

Похоже, вы могли бы использовать элемент управления 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>

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

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

Примеры:

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

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

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

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

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

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