В предыдущих статьях была представлена сущность единого входа, включая основные понятия файлов cookie, сеансов и перенаправления, основной процесс взаимодействия единого входа, важность файлов cookie и вопросы безопасности. Единый вход гарантирует, что вы должны быть аутентифицированы для доступа к веб-сайту и что вам нужно войти в систему только один раз при доступе к нескольким системам.
Полный план написания серии можно найти по адресу:Обзор серии
Индекс первой части серии:
- Общие сведения о сеансах и файлах cookie
- HTTP-перенаправление
- Введение в единый вход
- проблемы с безопасностью файлов cookie
- Введение в управление правами
Как правило, система имеет несколько ролей, и разные роли могут получать доступ к различным системным функциям.Назначая пользователям разные роли, определяются системные функции, к которым пользователи могут получить доступ.
Продолжайте знакомить с первой частью серии «Единый вход и управление полномочиями»: сущность единого входа и управления полномочиями. В этой статье рассказывается об управлении полномочиями, главным образом, в следующих аспектах:
- Общая модель управления правами
- Область проверки разрешения
- Базовая архитектура Shiro и точки расширения
- Краткое содержание первой части серии
Общая модель управления правами
Процесс проверки авторизации относительно прост и описывается следующим образом:
- После того, как пользователь успешно войдет в систему, его личная информация и информация о разрешениях будут сохранены в сеансе, который может быть сохранен в памяти и Redis;
- Когда пользователь обращается к другим страницам, они будут сопоставляться с данными о правах пользователя в соответствии с путем доступа, чтобы проверить, есть ли у них разрешение на доступ;
- Если есть разрешение, отобразить страницу доступа, если нет, предложить пользователю не иметь разрешения на доступ;
Как управлять и назначать разрешения пользователей, обычно абстрагируются следующие концепции сущностей:
- Пользователь: основной орган, осуществляющий доступ к системе;
- Роль: наименьшая единица для назначения разрешений и назначения разрешений пользователям через роли;
- Меню разрешений: наименьшая единица разрешений, роль настраивает несколько меню разрешений;
Кроме того, для облегчения управления правами будет выделена отдельная служба «Центр пользователей» для унифицированного управления пользователями, ролями и меню прав каждой системы. Меню разрешений синхронизируется с "Пользовательским центром" каждой подсистемой или обеспечивает функцию пакетного импорта. Правила идентификации меню разрешений должны быть согласованы заранее, и последовательная идентификация меню полезна для оценки перехвата разрешений.
Просто перехватите несколько страниц в нашем проекте, чтобы углубить ваше понимание:
-
При добавлении пользователя необходимо выбрать роль
-
При добавлении роли нужно выбрать меню разрешений
-
Меню разрешений синхронизируется каждой подсистемой
Область проверки разрешения
Пользователи имеют право на доступ к некоторым данным и управление ими, но это не означает, что они могут получить доступ ко всем данным.Они могут иметь доступ только к своим собственным данным и управлять ими, и они могут иметь доступ к данным и управлять ими только внутри группы. , Это более детальный контроль разрешений.
Место проверки разрешений может быть на переднем конце или на заднем конце. Внешний интерфейс отображает различные пункты меню и кнопки операций в соответствии с разрешениями текущего пользователя, а серверная часть проверяет легитимность операции в соответствии с разрешениями текущего пользователя и возвращает доступный набор данных. проверка разрешений также должна рассматриваться комплексно.
контролировать детализацию
Например, есть такой сценарий: есть интерфейс запроса заказа для внешних вызовов, который может возвращать детали заказа по номеру заказа.
Если есть правила для поиска номера заказа, и бэкэнд не оценивает владельца заказа, вы можете просмотреть информацию о заказах других людей, поэтому для проверки владельца заказа требуется более детальное суждение.
Кроме того, разрешения можно проверить с помощью двух уровней детализации ролей и разрешений меню:
<shiro:hasPermission name="permission1">
<h2>拥有permission1权限可以看到这里</h2>
</shiro:hasPermission>
<shiro:hasRole name="role">
<h2>拥有role角色可以看到这里</h2>
</shiro:hasRole>
Подтвердить местоположение
Чтобы сделать работу пользователя достаточно удобной, элементы меню и кнопки операций, с которыми пользователь не может работать, не нужно отображать, и их необходимо проверять на внешнем интерфейсе, например, добавлять пользовательские операции:
<shiro:hasPermission name="user:add">
<a href='user/add'>添加用户</a>
</shiro:hasPermission>
Недостаточно только фронтенд-верификации, можно обойти фронтенд-доступ, имитируя HTTP-запросы, бэкенд тоже нужно проверять, Широ предоставляет перехватчики для унифицированной обработки.
Базовая архитектура Широ и расширения
Shiro — это программное обеспечение с открытым исходным кодом под управлением apache, фреймворк безопасности, который управляет и проверяет удостоверения пользователей и разрешения.
Apache Shiro™ — это мощная и простая в использовании среда безопасности Java, которая выполняет аутентификацию, авторизацию, криптографию и управление сеансами.
В этой статье мы не будем вводить детали Широ, а только представим основные компоненты Широ, соответствующие общей модели управления правами.
Базовая архитектура Широ выглядит следующим образом:
- Тема: Сущность, взаимодействующая в настоящее время с пользователем, включая пользователей, сторонние службы, задачи кукурузы и т. д. Пользователю нужно использовать только ряд методов, предоставляемых объектом, для взаимодействия с внутренним модулем управления безопасностью в образ, соответствующий «пользователю» в модели;
- Аутентификатор: отвечает за проверку личности пользователя. Когда пользователь пытается войти в систему, он вызывает свой метод для аутентификации. Он вызывает одно или несколько Realms для проверки имени пользователя и пароля в соответствии с конфигурацией, соответствующей «операции входа пользователя». " в модели;
- Авторизатор: отвечает за проверку прав доступа пользователя. Когда пользователь обращается к странице, он может проверить права пользователя в соответствии с предоставленным им методом. Он также вызывает одно или несколько Realms для получения данных о правах пользователя, соответствующих «Иметь права доступа». в модели;
- SessionManager: Предоставляет надежный способ управления сеансами пользователей, что является уникальной функцией Shiro. Если это приложение Web/Servlet, оно будет использовать существующее управление сеансом по умолчанию. Если это не веб-приложение, Shiro будет использовать встроенный менеджер сессий. Он вызовет SessionDAO для сохранения сеанса, что соответствует «Управлению сеансом» в модели;
- CacheManager: Shiro получает доступ к внутренней системе хранения в модулях Authenticator, Authorizer и SessionManager. Использование управления кешем может повысить производительность доступа к данным и может быть легко интегрировано со сторонними фреймворками кеша, такими как Ehcache, Redis и т. д. .;
- Realms: Это мост между программами и пользовательскими данными и данными разрешений.Он предоставляет расширения в виде подключаемых модулей.Одно или несколько Realms можно настроить для обеспечения поддержки данных для модулей Authenticator и Authorizer;
- Криптография: обеспечивает поддержку шифрования и расшифровки данных, которая инкапсулирует связанные интерфейсы, упрощая понимание и использование;
Из приведенного выше введения видно, что основные компоненты Shiro соответствуют обобщенной «общей модели», которая помогает нам реализовать весь процесс проверки пользователей, проверки разрешений и управления сеансами, обеспечивая при этом управление кэшем, шифрование и инкапсуляцию дешифрования. для повышения производительности и безопасности, поддержки расширения с помощью подключаемых модулей Realm и пользовательских классов реализации для получения данных о пользователях и разрешениях.
Возьмем аутентификацию пользователя в качестве примера, чтобы проиллюстрировать процесс взаимодействия нескольких компонентов:
Краткое содержание первой части серии
На данный момент представлена первая часть цикла "Суть единого входа и управления правами". За 5 статей я довел суть того, что хочу сказать. Базовых понятий точно будет не хватать. Пополнить.
Чтобы восстановить суть технологии, абстрагируйте сложные технологии и структуры, чтобы сформировать относительно простое и понятное представление, которое можно лучше понять, расширить и применить.
Для единой регистрации с помощью файлов cookie и перенаправления http переход и аутентификация могут выполняться автоматически для достижения эффекта однократного входа в систему и доступа к нескольким подсистемам.
Ибо управление правами, зная его общую модель и процесс проверки вкупе со зрелой инфраструктурой реализации, может быстро, всесторонне и стабильно внедрить его и расширяться на этой основе.
Кроме того, файлы cookie и информация о полномочиях учетной записи пользователя очень важны, и необходимо постоянно накапливать знания о безопасности и улучшать ее безопасность.
Вторая часть в основном посвящена практике, она будет имитировать нашу систему для создания DEMO и использовать CAS и платформу Shiro для реализации единого входа и управления разрешениями. Кроме того, «пользовательский центр» будет абстрагирован для управления пользователями, ролями и меню разрешений Каждая подсистема синхронизирует свои собственные меню разрешений посредством синхронизации.
Индекс серии:
- Общие сведения о сеансах и файлах cookie
- HTTP-перенаправление
- Введение в единый вход
- проблемы с безопасностью файлов cookie
- Введение в управление правами