Когда Кунар работал над проектом, он взял на себя особенно важное требование: трансформировать управление полномочиями нашей серверной системы транзакций.
задний планВ то время управление полномочиями серверной системы было действительно беспорядочным, в том числе:
- По умолчанию в системе указано несколько ролей.Каждый атрибут пользователя может быть настроен только с одним атрибутом роли.То, что может делать каждая роль в коде, жестко закодировано (многие системы будут делать это на ранней стадии)
- Провели много кампаний, администратор почти каждой кампании индивидуально жестко закодирован и разбросан повсюду (жестко закодированы мы все)
- Помимо собственных администраторов Qunar, есть также администраторы поставщиков, которые используют этот сервер. В начале администраторы поставщиков имеют одинаковые права, позже администраторы поставщиков также должны поддерживать своих суперадминистраторов и обычных администраторов, а также могут назначать права своим людям в своих магазинах.
- Первоначально проект был написан с использованием сервлета, а позже изменен на springmvc, но многие интерфейсы сервлета все еще используются, что приводит к множеству имен интерфейсов, и классы, предоставляющие внешние интерфейсы, также встречаются повсюду.
- Имена интерфейсов тоже разные, и по именам интерфейсов в коде невозможно отличить фоновые интерфейсы от интерфейсных интерфейсов.
После некоторых тщательных исследований я решил переписать систему разрешений. Скажите, почему вы не использовали популярные фреймворки spring security и apache shiro, потому что пользователи в фоновом режиме входят в систему следующим образом: Сначала успешно войдите в систему через процесс входа на сайт qunar, затем под указанный домен, а затем фон будет передавать указанный инструментарий анализирует файлы cookie для получения информации о пользователе, которую нельзя изменить, и это несовместимо с двумя платформами, которые управляют своими собственными механизмами аутентификации и процессами авторизации.
Далее идет конкретное проектирование и разработка, как пошагово разобраться в этом бардаке?
- Во-первых, должен быть набор независимых и полныхRBAC(Role-Bases Access Control) функции управления моделью. Здесь у нас также много администраторов и фоновых модулей, поэтому нам нужно расширить модель RBAC: нам нужно ввести отделы на верхнем уровне пользователей и слой модулей разрешений на верхнем уровне точек разрешений, чтобы пользователей и точки доступа можно просмотреть в дереве. , прост в использовании
- После того, как вы сможете назначать разрешения и пользователей через роли, вы должны сосредоточиться на том, как назначать разрешения исходным «разрешениям».совместимый. Первый — это совместимость нескольких исходных атрибутов роли в системе, добавление соответствующей роли, назначение соответствующих разрешений и привязка пользователей, ранее настроивших роль, к роли RBAC, чтобы этот пользователь был в атрибуте роли один. Слой завершил миграцию разрешений, следующий шаг — совместимость разрешений активности, создаем нового администратора для каждой активности, привязываем к соответствующим ролям пользователей, которые ранее отвечали за активность, а затем настраиваем разрешения для управления активностью. соответствующие действия для этих ролей.
- С моделью управления исходные данные также могут быть совместимы, и следующим шагом является определение того, что перехватывать.интерфейс. Потому что интерфейсы довольно лажовые, как определить какие интерфейсы перехватывать?В случае, если нереально вручную проверять один за другим, написать скрипт и закинуть его на сервер фоновой системы, записать список URL-адресов, к которым обращаются фоновую систему и запустить ее на несколько дней.К большинству интерфейсов некоторые из них отсутствуют в сети, и они в основном не являются ядром.
- Следующим шагом является реализацияПерехват разрешенияТеперь получите текущего пользователя и доступный URL-адрес и оцените, есть ли разрешение на доступ в соответствии с данными, управляемыми моделью RBAC. Здесь более сложная ситуация, то есть многие ранние интерфейсы serlvet определяют разные интерфейсы через разные параметры, например, запрос страницы товара в продаже — /product.do?type=onsale, а запрос страницы готовая страница продукта /product.do ?type=offline, по этой причине я поддерживаю обнаружение параметров только в разрешениях.Когда обнаруживается, что настроенные разрешения содержат параметры, сопоставление запросов считывается один за другим для найти конечную точку разрешения, которая должна быть проверена, косвенно реализована правильноразрешение на данныеобработка.
- Перехват разрешений интерфейса завершен.Учитывая, что некоторые наши бэкенд-страницы сделаны jsp-страницами, на jsp-страницах их много.кнопкаВы можете определить, есть лиразрешение, отображается только при наличии разрешения, поэтому был разработан набор меток для проверки разрешения. Используйте метки, чтобы обернуть кнопки, которым необходимо определить полномочия, и передать соответствующий уникальный идентификационный код полномочий, и кнопки без полномочий не будут отображаться при загрузке страницы. Когда внешний и внутренний интерфейс разделены на более позднем этапе, то, отображаются ли эти кнопки на странице, изменяется, чтобы настроить интерфейс для оценки в первую очередь, и он не отображается по умолчанию, и интерфейс возвращается, чтобы иметь разрешение на показать его.
- На этом перехват разрешений не заканчивается, ведь каждая проверка будет включать в себя операции запроса нескольких таблиц, что увеличит доступ к базе данных, а само разрешение пользователя будет меняться реже, поэтому точек перехвата разрешений много. идтитайник
После того, как все это сделано, как обеспечить безопасность в Интернете? В то время его выпускали несколько раз поэтапно
- В первый раз запускаются все функции управления модели RBAC, затем настраиваются необходимые роли, и только небольшая функция переключается на управление перехватом с использованием нового фреймворка разрешений
- Во второй раз используйте новую структуру разрешений для управления всеми фоновыми функциями администратора Qunar.На этот раз рабочая нагрузка по настройке велика, почти все фоновые URL-адреса должны быть настроены заново, и должно быть выполнено распределение.
- В третий раз новая структура разрешений используется для управления функциями управления поставщика.На этот раз риск относительно высок, поэтому я решил выпустить его рано утром, когда все спят. В то время, учитывая, что многие поставщики могут не знать, как назначать разрешения своим магазинам на страницах, которые они предоставляют, сторона эксплуатации и обслуживания подготовила обучающую презентацию, а на стороне разработки я специально добавил функции, которые можно использовать в качестве суперадминистратора определенного администратора.Идентичность в магазине, чтобы помочь в обслуживании.
- В четвертый раз запускается специальная функция: согласно разрешениям, назначенным авторизованным пользователем, создается многоуровневое меню в фоновом режиме. Предпосылкой этого является то, что тип точки разрешения различает меню и кнопку и в то же время требует, чтобы под каждым модулем было только одно меню, чтобы гарантировать, что управление модулем разрешения и точкой разрешения является управлением фактический пункт меню и соответствующую страницу меню, чтобы в соответствии с пользовательскими разрешениями меню рассчитать древовидную структуру, состоящую из модулей разрешений и точек разрешений, а затем использовать JSTL для визуализации внешнего интерфейса на странице jsp.
На этом все переключение разрешений подошло к концу.
Позже, в соответствии с проектом, один за другим добавляются некоторые практические инструменты, применимые к большинству систем разрешений, в том числе: запрос назначенных ролей указанного пользователя, запрос текущих разрешений указанного пользователя, запрос, какие роли заданы назначено разрешение. Владение, запрос, какие пользователи имеют указанные разрешения и т. д. Эти функции могут значительно облегчить администратору разрешений ведение данных о разрешениях. Кроме того, он также поддерживает динамическое обновление разрешений пользователя в кэше. После изменения конфигурация разрешений, разрешения пользователей действуют в режиме реального времени. Существует функция, которая недоступна, но стоит упомянуть, а именно восстановление определенной операции администратора, которая может вовремя откатить данные разрешений после злонамеренной или неправильной операции.
Конечно, эта система разрешений может поддерживать множество расширений, например: концепция добавления супервайзера в отдел, супервайзер имеет сумму следующих разрешений сотрудников; не только пользователи могут назначать разрешения, но также и отделы могут быть назначены разрешения, и пользователи в отделе имеют назначения отдела. Когда отношение иерархии отдела имеет фактическое значение, разрешения наследуются и так далее. Они могут быть расширены по мере усложнения бизнеса, но пока в них нет необходимости.
Кроме того, у этой системы разрешений есть и сторона, которую вы не хотите контролировать, самое главное — горизонтальный перевыпуск. Горизонтальное переопределение само по себе очень тесно связано с бизнесом. Например, администратор поставщика хочет управлять продуктом. В это время он хочет проверить, принадлежит ли продукт этому поставщику. Затем ему нужно получить идентификатор продукта. В это время , вы можете столкнуться Теперь параметр идентификатора продукта может быть одним из productId, productID, id, pId и т. д. (разные разработчики определяют разные имена параметров), я, наконец, получил этот параметр, и иногда вы обнаружите, что иногда это значение это идентификатор продукта, а иногда и зашифрованное значение. Вы, наконец, сделали это.В это время бизнес изменился и появилась новая форма бизнеса: у крупного поставщика есть несколько мелких поставщиков, и тогда их продукты могут быть разделены... Это в основном объясняется тем, что горизонтальное превышение полномочий лучше всего осуществляется бизнес-уровнем. Это может быть сделано с полномочиями, но может быть исключено из некоторых предприятий. В то же время, если это делается на уровне управления полномочиями, требуются последующие действия. • Интерфейсы должны соответствовать определенным спецификациям.
конецВо время преобразования системы разрешений я экспортировал большое количество вики, чтобы представить трансформированную структуру разрешений, но членам группы по-прежнему было сложно самостоятельно настраивать разрешения, поэтому я сделал еще четыре публикации о новом управлении разрешениями, охватывая Подробная информация о методах, алгоритмах и использовании. Наконец получил титул: император власти.
(Заканчивать)