Система без мер безопасности очень опасна.Общие меры безопасности включают аутентификацию личности и управление полномочиями. Когда пользователь получает доступ, сначала необходимо проверить, является ли он законным пользователем, а затем проверить, какие операции пользователь может выполнять с этими ресурсами, и, наконец, обеспечить безопасный доступ. Существует много способов аутентификации личности, самый простой — это прямое имя пользователя и пароль, более распространенный в отрасли способ входа в систему и т. д. Также существует множество сред авторизации, таких как OAuth2, Shiro и т. д. В этой статье сначала объясняется концепция CAS и концепция модели управления правами на основе ролей (RBAC), затем разрабатывается таблица данных и, наконец, объясняется, как использовать Shiro для управления правами.
1. Аутентификация личности CAS
Центральная служба аутентификации (CAS) — это протокол единого входа в Интернет. Его цель — позволить одному пользователю получить доступ к нескольким приложениям, предоставив учетные данные только один раз.
1.1, понятие существительного
Ядром CAS является его Ticket и ряд операций по его обработке. Основными нотами CAS являются TGT, ST, PGT, PGTIOU и PT, среди которых TGT и ST являются нотами в протоколе CAS1.0 (базовый режим), а PGT, PGTIOU и PT — в CAS2.0. (режим агента) протокол счета. Кто генерирует эти билеты? Должны быть сопутствующие сервисы, основные сервисы это: KDC, AS, TGS. Среды тоже должны быть две: ТГК.
1.1.1 Билет CAS
1) TGT (Билет на выдачу билетов)
TGT — это входной билет, выдаваемый CAS (специально выдаваемый AS KDC) для пользователей. С помощью TGT пользователи могут подтвердить, что они успешно вошли в CAS. TGT инкапсулирует значение cookie и информацию о пользователе, соответствующую значению cookie. После того, как CAS успешно аутентифицирует пользователя, CAS создает файл cookie, записывает его в браузер, создает объект TGT и помещает его в собственный кэш.Идентификатор объекта TGT является значением файла cookie. Когда HTTP-запрос приходит снова, если есть файл cookie, сгенерированный CAS, CAS будет использовать значение файла cookie в качестве ключа для запроса, есть ли TGT в кеше.Если есть, это означает, что пользователь вошел в систему раньше , Если нет, пользователю необходимо повторно зарегистрироваться.
Короче говоря, как только такой билет получен, последующие приложения для различных других сервисных билетов (ST) устраняют необходимость отправлять информацию аутентификации (точный термин — учетные данные) в KDC.
2) СТ (Сервисный билет)
ST — это билет, выданный CAS (выданный TGS KDC) пользователю для доступа к услуге.
Когда пользователь обращается к сервису, сервис обнаруживает, что у пользователя нет ЗБ, и требует, чтобы пользователь обратился в CAS для получения ЗБ. Пользователь отправляет запрос в CAS для получения ST. Если запрос пользователя содержит файл cookie, CAS будет использовать значение файла cookie в качестве ключа для запроса наличия TGT в кэше. Если TGT есть, он будет использовать этот TGT, чтобы выдать ST и вернуть его пользователю. Пользователь использует ST для доступа к сервису, а сервис использует ST для проверки CAS.После прохождения проверки пользователю разрешается доступ к ресурсу.
Любая рабочая станция должна иметь действующий сервисный билет для доступа к приложениям в домене (Приложения). Если Service Ticket может быть получен правильно, это означает, что доверительные отношения между CASClient-CASServer установлены правильно.
3) PGT (Билет на предоставление прокси)
Учетные данные прокси для службы прокси. После того, как пользователь успешно входит в прокси-службу через CAS, CAS создает объект PGT, который кэшируется локально в CAS, возвращает значение PGT (строка UUID) в прокси-службу и сохраняет его в прокси-службе. После того, как прокси-служба получит PGT, она может выступать в качестве прокси-сервера для целевой службы (внутренней службы) и подавать заявку на PT для нее.
4) PT (прокси-билет)
PT — это доступ пользователя к целевой службе (внутренней службе) заметок. Если пользователь посещает веб-приложение, веб-приложению будет предложено предоставить ST, браузер будет использовать файл cookie для получения CAS ST, после чего вы сможете получить доступ к веб-приложению. Если пользователь посещает не веб-приложение, а использует структуру C/S, поскольку в структуре приложения C/S отсутствует файл cookie, поэтому пользователи не могут получить доступ к CAS ST самостоятельно, но через интерфейс для доступа к прокси сервис, благодаря прокси-сервису, чтобы получить PGT PT, прежде чем вы сможете получить доступ к этому приложению.
Резюме взаимосвязи между TGT, ST, PGT, PT
1: ST выдается TGT. После успешной аутентификации пользователя в CAS, CAS генерирует TGT, выдает ST с TGT, а значением атрибута ticketGrantingTicket в ST является объект TGT, а затем перенаправляет значение ST в клиентское приложение. .
2: PGT выдается ST. Пользователь использует ST для доступа к прокси-сервису, а прокси-сервис обращается к CAS для проверки ST (при передаче параметра PgtUrl в CAS).Если проверка ST прошла успешно, CAS выдает PGT с ST. TicketGrantingTicket в объекте PGT — это объект TGT, выдавший ST.
3: PT выдается PGT. Когда прокси-служба проксирует внутреннюю службу в CAS для получения PT, CAS получает объект PGT в соответствии с переданным параметром pgt, а затем вызывает свой метод grantServiceTicket для создания объекта PT.
1.1.2 Услуги CAS
Основные услуги CAS:
- KDC (Центр распределения ключей);
- AS (служба аутентификации) запрашивает учетные данные и выдает TGT;
- TGS (Служба выдачи билетов), попросите TGT и выдайте ST.
1.1.3, среда CAS
TGC (файл cookie для предоставления билетов)
Файл cookie, в котором хранятся учетные данные для аутентификации пользователя, используется при обмене данными между браузером и сервером CAS и может передаваться только по защищенному каналу (Https).Это учетные данные, используемые сервером CAS для уточнения личности пользователя.
1.2, принцип работы CAS
В процессе аутентификации единого входа CAS, после запроса используемого сервера приложений приложением, проверьте ST и TGT.Если они отсутствуют или неверны, перейдите на страницу входа на сервер аутентификации CAS, получите ST и TGT после пройти аутентификацию безопасности, а затем перенаправить на соответствующее приложение. Если сервер перенаправляется на другое приложение в течение жизненного цикла сеанса, он представит ST и TGT для аутентификации. Обратите внимание, что процесс получения TGT осуществляется через безопасность SSL протокол.
Более профессиональную и более подробную блок-схему принципа работы CAS я нашел в Интернете:
Профессиональная версия может быть более непонятной и трудной для понимания, вот популярная версия. С точки зрения непрофессионала это: Это эквивалентно тому, что пользователь, идущий на детскую площадку, сначала проверяет личность пользователя у двери (то есть ПРОВЕРЯЕТ ИДЕНТИФИКАТОР пользователя и ПАРОЛЬ), если пользователь проходит проверку, охранник игровой площадки (AS) предоставит пользователю карта двери (TGT).
Цель этой карты - сообщить различным местам парка развлечений, что пользователь вошел через переднюю дверь, а не через заднюю дверь, а также получил ключ для входа в это место.
Теперь у пользователя есть карта, но это не важно для пользователя, потому что пользователь приходит в парк развлечений не для того, чтобы получить эту карту, а чтобы посетить развлекательный проект.В это время пользователь имеет небоскреб и хочет играть .
В это время сервер колеса обозрения (клиент) остановил пользователя и запросил у пользователя билет на колесо обозрения (ST).Пользователь сказал, что у пользователя есть только одна дверная карта (TGT), тогда пользователю нужно только поставить TGT в сторону машины авторизации билетов (TGS) Освежить.
The ticket authorization machine (TGS) gives the user a Ferris wheel ticket (ST) according to the Ferris wheel where the user is currently, so that the user has the ticket of the Ferris wheel, and now the user can enter the Ferris wheel unimpeded играть.
Конечно, если пользователь хочет отдохнуть в кафе в парке развлечений после игры на колесе обозрения, пользователю нужно только принести дверную карту (TGT), Подойдите к автомату авторизации билетов (TGS) соответствующего кафе и проведите пальцем по экрану. это чтобы получить кофе.Вы можете войти в кофейню с билетом (ST) зала
Когда пользователь покидает игровую площадку, он хочет использовать этот TGT, чтобы оплатить поездку домой. Извините, срок действия TGT пользователя истек, и TGT пользователя был уничтожен с того момента, как пользователь покинул игровую площадку.
2. Ролевая модель управления правами
Наиболее распространенной моделью разрешений в отрасли является RBAC (управление доступом на основе ролей).Основная концепция заключается в назначении пользователям понятия «роли».В системе пользователи могут получать соответствующие разрешения, назначая роли.Роль, Роль может иметь несколько разрешений, чтобы обеспечить гибкую настройку разрешений.
2.1 Базовая модель RBAC
Наиболее основной моделью RBAC состоит из трех средств «пользователей», «ролей», «разрешения». Пользователь может иметь несколько ролей. Одна роль может иметь несколько разрешений, и отношения между ними могут быть многополей. Может также быть намного больше.
2.2. Представьте модель RBAC в групп пользователей
Если количество пользователей относительно велико, при добавлении новой роли необходимо переназначить новую роль большому количеству пользователей, что требует огромного объема инженерных работ.В этом случае может быть введено понятие группы пользователей. . Если сценарии использования некоторых пользователей относительно непротиворечивы и базовые, таких пользователей можно упаковать в группу, а роли и разрешения можно назначить на основе объектов в этой группе. Все разрешения, принадлежащие конечному пользователю = разрешения, принадлежащие пользователю лично + разрешения, принадлежащие группе пользователей, к которой принадлежит пользователь.
2.3 Модель RBAC классификации ролей
В некоторых бизнес-сценариях роли верхнего уровня должны наследовать все разрешения ролей нижнего уровня, в этом случае необходимо использовать модель наследования ролей RBAC. В настоящее время, в дополнение к определению ролей, также необходимо управлять отношениями между ролями и отражать иерархические отношения ролей через отношения, чтобы добиться эффекта наследования разрешений. Существует два основных типа отношений наследования ролей: древовидная диаграмма и ориентированный ациклический граф.
2.4, ограничение роли модели RBAC
В некоторых продуктах или системах может потребоваться изолировать некоторые роли и запретить их одновременное назначение одному человеку, например, не быть одновременно спортсменом и судьей. Поэтому некоторые роли имеют взаимные демонтажные отношения. Кроме того, ограничение может быть количественным, например, один и только один администратор в группе продуктов, и нельзя удалять или переназначать других администраторов.
В соответствии с различными потребностями бизнеса существует множество форм ограничений.Следует отметить, что вы должны не только полагаться на внутренние ограничения, но и отображать четкие правила и соответствующие ограничения на внешнем интерфейсе, чтобы избежать ошибок пользователя.
2.5. Основные элементы управления правами
Основными элементами управления разрешениями являются: пользователи, роли, ресурсы, операции и разрешения.
1. Пользователь Конкретный оператор прикладной системы, пользователь, может владеть информацией о разрешениях, может принадлежать к 0-n ролям и может принадлежать к 0-n группам. Его набор разрешений представляет собой набор его собственных разрешений, разрешений каждой роли, к которой он принадлежит, и разрешений каждой группы, к которой он принадлежит. Связь между ним и разрешениями, ролями и группами представляет собой отношение n-to-n.
2. Группа пользователей (необязательно) Чтобы лучше управлять пользователями, пользователи группируются и классифицируются, что для краткости называется группировкой пользователей. Группы также имеют высшие и низшие отношения и могут формировать древовидное представление. В реальных ситуациях мы знаем, что группы также могут иметь свою собственную информацию о роли и информацию о разрешениях.
3. Роль Для классификации и управления многими пользователями с одинаковыми разрешениями определяется понятие ролей, таких как системный администратор, администратор, пользователь, гость и другие роли. Роль имеет отношения «начальник-подчиненный» и может формировать древовидное представление.Разрешения родительской роли представляют собой комбинацию разрешений самой роли и всех ее подролей. Таким же образом можно отправить пользователя родительской роли и группу родительской роли.
4. Ресурсы Единичный объект управления правами, назовем его ресурсом в широком смысле, это может быть человек, товар, файл, страница и Т. Д. 5. Операция Фактическая операция, выполняемая с ресурсом, например чтение, запись, редактирование и т. д.
6. Разрешения Ресурсы + операции составляют точку управления разрешениями.
Отношения между объектами включают в себя:
- Это связано
- отношения наследования
- Ограниченные отношения (взаимное исключение, ограничение диапазона, ограничение границы, ограничение поля)
3. Дизайн таблицы данных
В соответствии с моделью RBAC базу данных можно спроектировать следующим образом:
1. Таблица продуктов (t_product_info)
| Имя поля | поле | тип | Примечание |
|---|---|---|---|
| Идантификационный номер продукта | pro_id | int(11) | автоматическое приращение |
| Название продукта (англ.) | name_en | varchar(50) | not null |
| Слой названия продукта (средний) | name_ch | varchar(50) | not null |
| основатель | creator | varchar(50) | not null |
| владелец | owner | varchar(50) | not null |
| описывать | description | varchar(255) | |
| время создания | create_time | timestamp | not null |
2. Таблица членов продукта (t_product_member)
| Имя поля | поле | тип | Примечание |
|---|---|---|---|
| Идентификатор записи | id | int(11) | автоматическое приращение |
| идантификационный номер продукта | pro_id | int(11) | fk:t_produck_info |
| ID пользователя | member_id | int(11) | not null |
| время создания | create_time | timestamp | not null |
3. Таблица информации о пользователе (t_user_info)
| Имя поля | поле | тип | Примечание |
|---|---|---|---|
| Идентификатор пользователя | user_id | int(11) | not null |
| английское имя | nike_name | varchar(10) | not null |
| китайское имя | real_name | varchar(10) | not null |
| время создания | create_time | timestamp | not null |
| Время обновления | update_time | timestamp | not null |
4, пользовательский ролик таблицы (T_USER_ROLE)
| Имя поля | поле | тип | Примечание |
|---|---|---|---|
| Идентификатор записи | id | int(11) | автоматическое приращение |
| Идентификатор пользователя | user_id | int(11) | not null |
| идентификатор роли | role_id | варчар (50) | not null |
| время создания | create_time | timestamp | not null |
5. Таблица ролей (t_role)
| Имя поля | поле | тип | Примечание |
|---|---|---|---|
| идентификатор записи | id | int(11) | автоматическое приращение |
| идентификатор роли | role_id | варчар (50) | не нуль, например: A ~ USER |
| Имя роли | role_name | варчар (50) | not null |
| объект | object | варчар (50) | not null |
| Объектный идентификатор | object_id | варчар (50) | not null |
| Примечания к ролям | comment | varchar(255) | |
| время создания | create_time | timestamp | not null |
6, таблица базовых ролей (t_role_base)
| Имя поля | поле | тип | Примечание |
|---|---|---|---|
| идентификатор записи | id | int(11) | автоматическое приращение |
| идентификатор роли | role_id | варчар (50) | не нуль, например: A~USER |
| Имя роли | role_name | варчар (50) | not null |
| Примечания к ролям | comment | varchar(255) | |
| разрешение | permission | varchar(255) | not null |
| время создания | create_time | timestamp | not null |
7. Таблица разрешений роли (t_role_permission)
| Имя поля | поле | тип | Примечание |
|---|---|---|---|
| идентификатор записи | id | int(11) | автоматическое приращение |
| идентификатор роли | role_id | варчар (50) | fk:t_role->role_id |
| разрешение | permission | варчар (255) | not null |
| идентификатор базового персонажа | role_base_id | варчар (50) | fk:t_role_base->role_id |
| время создания | create_time | timestamp | not null |
8. Таблица групп пользователей (t_user_group, необязательно)
| Имя поля | поле | тип | Примечание |
|---|---|---|---|
| Идентификатор группы | id | int(11) | автоматическое приращение |
| Название группы | group_name | варчар (50) | not null |
| описание группы | group_desc | варчар (255) | not null |
| время создания | create_time | timestamp | not null |
9. Таблица групповых ролей (t_user_group_role, необязательно)
| Имя поля | поле | тип | Примечание |
|---|---|---|---|
| идентификатор записи | id | int(11) | автоматическое приращение |
| идентификатор группы | role_id | варчар (50) | not null |
| идентификатор роли | role_id | варчар (255) | not null |
| время создания | create_time | timestamp | not null |
10. Таблица разрешений пользователей (t_user_permission, необязательно)
| Имя поля | поле | тип | Примечание |
|---|---|---|---|
| идентификатор записи | id | int(11) | автоматическое приращение |
| Идентификатор пользователя | role_id | варчар (50) | not null |
| разрешение | permission | варчар (255) | not null |
| время создания | create_time | timestamp | not null |
В-четвертых, роль и авторитет Dot Design
Весь процесс контроля разрешений можно описать так: «кто» выполняет «что» над «чем», таким образом, работа, которую нам нужно выполнить, это: проектирование ролей, определение ресурсов и определение операций с ресурсами. Чтобы описать подробно, аутентификация предназначена для получения того, какие операции могут выполняться с этими ресурсами в соответствии с идентификатором (ролью) пользователя, а операции с ресурсами рассматриваются как независимый орган власти.
4.1. Определить роли пользователей в системе
Генерал - это использование модели «универсальной роли».
Общие определения универсальных ролей: администратор, менеджер, участник, гость Назначение разрешений общей роли: 1) Super_admin, имеет системные все права 1) Администратор продукта с текущим владением продуктом; 2) Менеджер продукта, не имеет прав на удаление, изменение, добавление участников и т. д. 3) Продукт MEMEBER, вы можете просматривать, изменять информацию, а не добавлять участников; 4) Продукт Гость, вы можете только просматривать
Пример роли: Обычно можно определить примерные роли: «Точка ресурса + универсальная роль + идентификатор ресурса».
Примечание. Ресурсы могут быть продуктами, страницы, меню и т. Д.
4.2. Определить ресурсы и операции в системе
Наиболее распространенными ресурсами в общих системах являются: Продукты (P) Как правило, основные операции над ресурсами включают в себя: Добавить (СОЗДАТЬ), удалить (УДАЛИТЬ), изменить (РЕДАКТИРОВАТЬ), просмотреть (ПРОСМОТР)
Ресурсов в системе конечно больше, чем продуктов.В то же время гранулярность продуктов слишком грубая, и ею можно управлять более тонко.Конечно, все определяет соответствующие ресурсные точки и операции согласно реальные потребности бизнеса.
4.3 Тело прав стратегии
Политика контроля разрешений принимает пятерку следующим образом:
资源：操作：实例：BU：密级
Среди них ресурс может быть персоной, требованием, файлом и т. д.; операция — операция над ресурсом; экземпляр — идентификатор продукта или идентификатор пользователя; БУ, уровень безопасности используется для управления видимостью разных БУ и разных модулей безопасности
Пять, плюс реализация аутентификации управления правами
JAVA может использовать фреймворк SHIRO, одно из самых простых приложений Shiro: 1) Код приложения авторизуется субъектом, а субъект делегируется SecurityManager; 2) Нам нужно внедрить Realm в систему безопасности Широ, чтобы SecurityManager мог получить законных пользователей и их разрешения для суждения;
Основных задач Широ на самом деле две: аутентификация личности и проверка разрешений, которые будут представлены отдельно ниже.
5.1. Аутентификация личности
Из анализа предыдущей статьи мы знаем, что пользовательская логика проверки подлинности должна наследовать только AuthenticationRealm. Переопределите следующий интерфейс для аутентификации:
@Override
protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token){}
Вышеупомянутый интерфейс, параметр AuthenticationToken, может быть реализован с помощью пользовательских подклассов.Фреймворк предоставляет: UsernamePasswordToken, CasToken.
Если вы входите в систему с помощью имени пользователя и пароля, создайте UsernamePasswordToken, а затем извлеките данные, чтобы проверить правильность имени пользователя и пароля; если вы входите с помощью CAS, создайте CasToken с помощью билета, а затем взаимодействуйте со службой CAS для проверьте, действителен ли билет. Если проверка пройдена, будет сгенерирована AuthenticationInfo. На этом аутентификация завершена.
Самый простой пароль пользователя для проверки идентификационных кодовПроверка метода CAS должна сначала иметь систему CAS.Я не буду объяснять, как проверить метод CAS здесь.Позвольте мне рассказать о том, как войти в систему с паролем пользователя для проверки личности.Процесс аутентификации такой же.
Настройте AuthenticationRealm:
public class MyRealm1 implements AuthenticatingRealm {
@Override
protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException {
String username = (String)token.getPrincipal(); //得到用户名
String password = new String((char[])token.getCredentials()); //得到密码
//取数据库中看用户名是否有效
//checkUserInfo();
//如果身份认证验证成功，返回一个AuthenticationInfo实现；
return new SimpleAuthenticationInfo(username, password, getName());
}
}
5.2, проверка разрешения
Главное, что нужно сделать при проверке разрешений, — это завершить процесс суждения «узнать из базы данных, включают ли все разрешения, которыми обладает пользователь, разрешения, которые в настоящее время проверяются», поэтому главное, что нужно сделать, это: 1) Узнать из базы данных Все разрешения, которые есть у пользователя; 2) Проанализируйте разрешения, чтобы увидеть, включены ли разрешения, которые необходимо проверить.
1. Шаг 1: Получите информацию о правах пользователяПроцесс получения информации о разрешениях пользователя завершается в Realm, наследует AuthorizingRealm, а затем переопределяет следующие два интерфейса для получения информации о разрешениях пользователя:
//获取用户身份信息，Authorization前需要先获取用户身份信息
@Override
protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token){}
//获取用户权限信息
@Override
protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principalCollection){
}
Процесс запроса информации о разрешениях обычно выглядит следующим образом: 1) Чтение разрешений, назначенных пользователем в области из базы данных; 2) Разрешения, используемые для чтения ролей пользователей из базы данных (роли включают роли экземпляра и роли BASE). 3) Конечные полномочия пользователя: собственные полномочия пользователя + полномочия роли пользователя.
2. Шаг 2: Проверка разрешения
1) Если проверка роли пройдена, вызываем hasRole и сравниваем с пришедшей ролью;
2) Если он проходит проверку разрешения, вызовите isPermitted(...) и сравните его с входящим разрешением.
Внутренняя логика shiro следующая: сначала строка разрешения преобразуется в соответствующий экземпляр Permission через PermissionResolver, по умолчанию используется WildcardPermissionResolver, то есть WildcardPermission конвертируется в wildcard, затем вызывается Permission.implies(Permission p) для сравнения с входящими разрешениями одно за другим, если есть совпадение, возвращает true, в противном случае — false.
6. Ссылки
1,Официальная документация Широ2,apache shiro3.следуй за мной Широ4.Унифицированная аутентификация и авторизация удостоверений в микросервисной архитектуре5.Краткое описание системы единого входа для единого входа, служб централизованной аутентификации CAS и OAuth с открытой авторизацией.
Я желаю всем успехов, счастливого дня!