1. Управление полномочиями

1.1 Что такое управление правами

По сути, системы, в которых участвует пользователь, должны осуществлять управление правами.Управление правами относится к категории системной безопасности.Управление правами реализует контроль доступа пользователей к системе в соответствии с правилами безопасности илистратегия безопасностиПользователи управления могут получить доступ и могут получить доступ только к тем ресурсам, на которые они авторизованы.

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

1.2 Аутентификация пользователя

1.2.1 Концепция

Аутентификация личности — это процесс определения того, является ли пользователь законным пользователем. Наиболее часто используемый простой метод аутентификации заключается в том, что система проверяет, соответствуют ли имя пользователя и пароль, введенные пользователем, имени пользователя и паролю, хранящимся в системе, чтобы определить, верна ли личность пользователя. Для принятияотпечаток пальцаДля таких систем, как аппаратные ключи, вам нужно показать свой отпечаток пальца; для таких систем, как аппаратные ключи, вам нужно провести картой.

1.2.2 Процесс аутентификации имени пользователя и пароля

1.2.3 Ключевые объекты

В приведенной выше блок-схеме необходимо понимать следующие ключевые объекты:

Тема: тема

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

Принципал: идентификационная информация

Это идентификация субъекта для аутентификации.Идентификация должна быть уникальной, например, имя пользователя, номер мобильного телефона, адрес электронной почты и т. д. Субъект может иметь несколько идентификаторов, но должен иметь основного принципала.

учетные данные: учетная информация

Это информация о безопасности, которую знает только субъект, например пароли, сертификаты и т. д.

1.3 Авторизация

1.3.1 Концепция

Авторизация или контроль доступа определяет, кто и к каким ресурсам может получить доступ. После аутентификации субъекту необходимо назначить разрешения на доступ к ресурсам системы, к некоторым ресурсам нельзя получить доступ без разрешения.

1.3.2 Процесс авторизации

Оранжевым цветом на рисунке ниже обозначен процесс авторизации.

1.3.3 Ключевые объекты

Авторизацию можно просто понимать как то, кто выполняет операцию «Как» над чем (что):

Кому, субъекту (Subject), субъекту необходимо получить доступ к ресурсам в системе.

Что, то есть ресурсы (Resource), такие как системные меню, страницы, кнопки, методы класса, системная товарная информация и т.д. Ресурс включает тип ресурса и экземпляр ресурса, например, информация о товаре является типом ресурса, товар с типом t01 является экземпляром ресурса, а информация о товаре с серийным номером 001 также принадлежит экземпляру ресурса.

Как, разрешение/разрешение (Permission), указывает разрешение субъекта на работу с ресурсом.Бессмысленно оставлять ресурс, например, разрешение на запрос пользователя, разрешение на добавление пользователя, разрешение на вызов метода класса, разрешение на изменение номера пользователя 001, и т. д. Через разрешения вы можете узнать, какие разрешения на операции есть у субъекта на каких ресурсах.

Разрешения делятся на общие и подробные. Общие разрешения относятся к типам ресурсов, а подробные разрешения относятся к экземплярам ресурсов.

Отношения между субъектами, ресурсами и разрешениями следующие:

1.3.4 Модель разрешений

Субъекты, ресурсы и разрешения в предыдущем разделе представлены моделью данных.

Тема (аккаунт, пароль)

Ресурс (имя ресурса, адрес доступа)

Разрешения (имя органа, идентификатор ресурса)

роль (имя роли)

Отношение ролей и разрешений (идентификатор роли, идентификатор разрешения)

Связь субъекта и роли (идентификатор субъекта, идентификатор роли)

Как показано ниже:

Как показано ниже:

Обычно в корпоративной разработке таблицы ресурсов и разрешений объединяются в одну таблицу разрешений следующим образом:

Ресурс (имя ресурса, адрес доступа)

Разрешения (имя органа, идентификатор ресурса)

В сочетании как:

Разрешения (имя органа, имя ресурса, адрес доступа к ресурсу)

Приведенный выше рисунок часто называют общей моделью управления полномочиями.Однако предприятия будут изменять приведенный выше рисунок в соответствии с характеристиками самой системы во время разработки.Однако пользователи, роли, разрешения, отношения между пользователями и ролями и необходимо понимать отношения власти.

1.3.5 Назначение разрешений

При назначении полномочий субъекту субъекту разрешается управлять ресурсом только в рамках полномочий.Например, если пользователю u01 назначено право изменять продукт, пользователь u01 может только изменять продукт.

Данные назначения разрешений обычно необходимо сохранять, и таблица создается в соответствии с приведенной выше моделью данных, а информация о разрешениях пользователя хранится в базе данных.

1.3.6 Контроль разрешений

Пользователь может управлять ресурсами в рамках полномочий после того, как пользователь получит полномочия.Система не знает, имеет ли субъект полномочия доступа и должен ли он контролировать доступ пользователя.

1.3.6.1 Управление доступом на основе ролей

Управление доступом на основе ролей RBAC (управление доступом на основе ролей) представляет собой управление доступом на основе ролей. Например, если роль субъекта — генеральный менеджер, он может запрашивать отчеты о работе предприятия, запрашивать информацию о зарплате сотрудников и т. д. Процесс управления доступом составляет:

Логический код суждения на приведенном выше рисунке можно понимать как:

if(main.hasRole("идентификатор роли генерального менеджера")){

Проверить зарплату

}

Недостатки: уровень детализации управления доступом на основе ролей относительно груб. субъект является генеральным менеджером или менеджером отдела», масштабируемость системы плохая.

Измените код следующим образом:

if(subject.hasRole("идентификатор роли генерального менеджера") || subject.hasRole("идентификатор роли менеджера отдела")){

Проверить зарплату

}

1.3.6.2 Управление доступом на основе ресурсов

Управление доступом на основе ресурсов RBAC (управление доступом на основе ресурсов) — это управление доступом, ориентированное на ресурсы.Например, субъект должен иметь разрешение на запрос информации о зарплате для запроса информации о зарплате сотрудника и т. д. Процесс управления доступом выглядит следующим образом:

Логический код суждения на приведенном выше рисунке можно понимать как:

if(main.hasPermission("Запрос идентификатора разрешения на зарплату")){

Проверить зарплату

}

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

2 решения для управления правами

2.1 Крупный и мелкий размер частиц

2.1.1 Что такое грубое и мелкое зерно

Управление типами ресурсов называется общим управлением полномочиями, которое управляет только меню, кнопками и методами.Например, у пользователя есть полномочия управлять пользователем и экспортировать сведения о заказе. Управление экземплярами ресурсов называется детальным управлением разрешениями, то есть разрешениями на управление уровнем данных.Например, пользователю разрешено изменять только информацию о сотрудниках отдела, а пользователю разрешено только экспортировать детали заказа, созданные им самим.

2.1.2 Как добиться крупнозернистости и мелкозернистости

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

Для детального управления разрешениями не рекомендуется создавать функции на уровне архитектуры системы, поскольку управление на уровне данных является бизнес-требованием системы. С изменением бизнес-требований бизнес-функции, вероятно, изменятся. имеют разрешения на уровне данных. Персонализированная разработка контролируется на бизнес-уровне. Например, пользователям разрешено изменять только информацию о продукте, созданную ими самими. Вы можете добавить реализацию проверки в интерфейс службы. Интерфейс службы должен передавать удостоверение текущего оператора, который сравнивается с личностью создателя информации о продукте.Допускается изменение информации о продукте.

2.2 На основе перехвата URL

Перехват на основе URL-адресов является широко используемым методом управления правами на предприятиях.Идея реализации заключается в следующем: настроить каждый URL-адрес, управляемый системой, в таблице разрешений, сопоставить разрешения с ролями и назначить роли пользователям.Доступ пользователей к системным функциям фильтруется. через фильтры.Фильтр получает URL-адрес, к которому обращается пользователь, и до тех пор, пока URL-адрес, к которому осуществляется доступ, является URL-адресом в роли, назначенной пользователем, он будет продолжать получать доступ.

Как показано ниже:

2.3 Использование инфраструктуры управления правами

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

3 Реализация на основе перехвата URL

3.1 Подготовка окружающей среды

jdk: 1.7.0_72

веб-контейнер: tomcat7

Системная структура: springmvc3.2.0+mybatis3.2.7 (подробности см. в плане урока springmvc)

Передний пользовательский интерфейс: jquery easyUI1.2.2

3.2 База данных

Создать базу данных mysql5.1

Создайте таблицы пользователей, таблицы ролей, таблицы разрешений, таблицы отношений разрешений ролей и таблицы отношений ролей пользователей.

Импортируйте скрипт, сначала импортируйте shiro_sql_talbe.sql, а затем импортируйте shiro-sql_table_data.sql.

3.3 класс идентификатора пользователя activeUser

Когда пользователь входит в систему успешно, информация activeUser записывается, и activeUser сохраняется в сеансе.

public class ActiveUser implements java.io.Serializable {

private String userid;//用户id

private String usercode;// 用户账号

private String username;// 用户名称

 

private List<SysPermission> menus;// 菜单

private List<SysPermission> permissions;// 权限

3.4 anonymousURL.properties

анонимныйURL.properties общедоступный адрес, к которому можно получить доступ без аутентификации.

3.5 commonURL.properties

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

3.6 Перехватчик аутентификации пользователя

Используйте перехватчик springmvc для перехвата аутентификации пользователя. Если пользователь не войдет в систему, он перейдет на страницу входа. Эту функцию также можно реализовать с помощью фильтра.

public class LoginInterceptor implements HandlerInterceptor {

 

// 在进入controller方法之前执行

// 使用场景：比如身份认证校验拦截，用户权限拦截，如果拦截不放行，controller方法不再执行

@Override

public boolean preHandle(HttpServletRequest request,

HttpServletResponse response, Object handler) throws Exception {

 

// 校验用户访问是否是公开资源地址(无需认证即可访问)

List<String> open_urls = ResourcesUtil.gekeyList("anonymousURL");

 

// 用户访问的url

String url = request.getRequestURI();

for (String open_url : open_urls) {

if (url.indexOf(open_url) >= 0) {

// 如果访问的是公开 地址则放行

return true;

}

}

 

// 校验用户身份是否认证通过

HttpSession session = request.getSession();

ActiveUser activeUser = (ActiveUser) session.getAttribute("activeUser");

if (activeUser != null) {

// 用户已经登陆认证，放行

return true;

}

// 跳转到登陆页面

request.getRequestDispatcher("/WEB-INF/jsp/login.jsp").forward(request,

response);

return false;

}

3.7 Перехватчик авторизации пользователя

Используйте перехватчик springmvc для перехвата URL-адресов доступа пользователя. Если URL-адрес, к которому обращается пользователь, не имеет назначенных разрешений, он перейдет на страницу запроса о несанкционированной операции (refuse.jsp).Эта функция также может быть реализована с помощью фильтра.

public class PermissionInterceptor implements HandlerInterceptor {

 

// 在进入controller方法之前执行

// 使用场景：比如身份认证校验拦截，用户权限拦截，如果拦截不放行，controller方法不再执行

// 进入action方法前要执行

@Override

public boolean preHandle(HttpServletRequest request,

HttpServletResponse response, Object handler) throws Exception {

// TODO Auto-generated method stub

// 用户访问地址：

String url = request.getRequestURI();

 

// 校验用户访问是否是公开资源地址(无需认证即可访问)

List<String> open_urls = ResourcesUtil.gekeyList("anonymousURL");

// 用户访问的url

for (String open_url : open_urls) {

if (url.indexOf(open_url) >= 0) {

// 如果访问的是公开 地址则放行

return true;

}

}

//从 session获取用户公共访问地址（认证通过无需分配权限即可访问）

List<String> common_urls = ResourcesUtil.gekeyList("commonURL");

// 用户访问的url

for (String common_url : common_urls) {

if (url.indexOf(common_url) >= 0) {

// 如果访问的是公共地址则放行

return true;

}

}

// 从session获取用户权限信息

 

HttpSession session = request.getSession();

 

ActiveUser activeUser = (ActiveUser) session.getAttribute("activeUser");

 

// 取出session中权限url

// 获取用户操作权限

List<SysPermission> permission_list = activeUser.getPermissions();

// 校验用户访问地址是否在用户权限范围内

for (SysPermission sysPermission : permission_list) {

String permission_url = sysPermission.getUrl();

if (url.contains(permission_url)) {

return true;

}

}

 

// 跳转到页面

request.getRequestDispatcher("/WEB-INF/jsp/refuse.jsp").forward(

request, response);

return false;

}

 

3.8 Вход пользователя

Пользователь вводит учетную запись пользователя и пароль для входа в систему, и логин успешно записывает идентификационную информацию пользователя (учетная запись пользователя, пароль, меню полномочий, URL-адрес полномочий и т. д.) в класс activeUser и записывает ее в сеанс.

3.8.1 controller

//用户登陆提交

@RequestMapping("/loginsubmit")

public String loginsubmit(HttpSession session,String usercode,String password,String randomcode) throws Exception{

 

//校验验证码

//从session获取正确的验证码

String validateCode = (String)session.getAttribute("validateCode");

if(!randomcode.equals(validateCode)){

//抛出异常：验证码错误

throw new CustomException("验证码 错误 ！");

}

//用户身份认证

ActiveUser activeUser = sysService.authenticat(usercode, password);

//记录session

session.setAttribute("activeUser", activeUser);

return "redirect:first.action";

}

3.8.2 сервисный интерфейс

/**

 *

 * <p>

 * Title: authenticat

 * </p>

 * <p>

 * Description:用户认证

 * </p>

 *

 * @param usercode

 *            用户账号

 * @param password

 *            用户密码

 * @return ActiveUser 用户身份信息

 * @throws Exception

 */

public ActiveUser authenticat(String usercode, String password)

throws Exception;

 

// 根据账号查询用户

public SysUser findSysuserByUsercode(String usercode) throws Exception;

 

// 根据用户id获取权限

public List<SysPermission> findSysPermissionList(String userid)

throws Exception;

 

// 根据用户id获取菜单

public List<SysPermission> findMenuList(String userid) throws Exception;