1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/pcore-UMS

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
Внести вклад в разработку кода
Синхронизировать код
Отмена
Подсказка: Поскольку Git не поддерживает пустые директории, создание директории приведёт к созданию пустого файла .keep.
Loading...
Readme.osc.md

Collection<? extends GrantedAuthority> authorities = authentication.getAuthorities();

  1. Данный фреймворк по умолчанию реализует метод hasPermission(Authentication, HttpServletRequest) для контроля доступа на основе разрешений, используя интерфейс UriAuthoritiesPermissionEvaluator. Условием использования этого интерфейса является то, что приложение использует RESTful API. Если же используется не RESTful API, следует использовать интерфейс hasPermission(Authentication, String, String) для контроля доступа. Этот интерфейс реализуется с помощью аннотации @PerAuthorize("hasPermission('/users', 'list')"), которая должна быть активирована с помощью аннотации @EnableGlobalMethodSecurity(prePostEnabled = true).

UpdateCacheOfRolesResourcesService (https://gitee.com/pcore/UMS/blob/master/rbac/src/main/java/top/dcenter/ums/security/core/api/permission/service/UpdateCacheOfRolesResourcesService.java):

  • Используется для обновления и кэширования разрешений на основе ролей (роль/многопользовательская/SCOPE). При каждом обновлении роли URI (ресурса) необходимо вызывать этот интерфейс. Рекомендуется реализовать интерфейс RolePermissionsService, который автоматически публикует событие UpdateRolesResourcesEvent через AOP.

  • Рекомендации:

    1. Контроль разрешений на основе роли: реализовать обновление и кэширование разрешений для всех ролей URI (ресурсов) в локальной памяти.
    2. Контроль разрешений на основе SCOPE: ситуация немного сложнее, но типов SCOPE мало, и можно также реализовать кэширование в локальной памяти.
    3. Контроль разрешений на основе многопользовательской системы: ситуация более сложная, и при небольшом количестве арендаторов можно полностью кэшировать в локальной памяти, но обычно это нереально, и необходимо использовать такие инструменты, как Redis для кэширования в памяти.

RolePermissionsService (https://gitee.com/pcore/UMS/blob/master/rbac/src/main/java/top/dcenter/ums/security/core/api/permission/service/RolePermissionsService.java):

  • Обновляет и запрашивает разрешения на основе ролей, многопользовательских систем и SCOPE. В основном используется для добавления разрешений к ролям.
  • Обратите внимание:
    1. При добавлении ресурсов используйте PermissionType.getPermission() для стандартизации формата разрешений, так как необходимо поддерживать RESTful API и сопоставлять HTTP-методы с соответствующими разрешениями при авторизации.
    2. Если вы реализуете интерфейс UpdateCacheOfRolesResourcesService, но не реализуете RolePermissionsService, необходимо вызвать соответствующий метод UpdateCacheOfRolesResourcesService при изменении или добавлении разрешений на ресурсы на основе «роли/многопользовательской/SCOPE». Есть два способа: опубликовать событие или напрямую вызвать соответствующую службу.
// 1. Рекомендуемый способ использования событий (асинхронное выполнение)
applicationContext.publishEvent(new UpdateRolesResourcesEvent(true, UpdateRoleResourcesDto);
// 2. Прямой вызов службы
// Ролевые разрешения ресурсов
UpdateCacheOfRolesResourcesService.updateAuthoritiesByRoleId(roleId, resourceClass, resourceIds);
// Многопользовательские ролевые разрешения ресурсов
UpdateCacheOfRolesResourcesService.updateAuthoritiesByRoleIdOfTenant(tenantId, roleId, resourceClass, resourceIds);
// Разрешения ресурсов на основе SCOPE
UpdateCacheOfRolesResourcesService.updateAuthoritiesByScopeId(scopeId, roleId, resourceClass, resourceIds);
// Групповые разрешения ролей
UpdateCacheOfRolesResourcesService.updateRolesByGroupId(groupId, roleIds);
// Многопользовательские групповые разрешения ролей
UpdateCacheOfRolesResourcesService.updateRolesByGroupIdOfTenant(tenantId, groupId, roleIds);
3. Реализуйте этот интерфейс RolePermissionsService и не выполняйте вышеуказанные операции, поскольку он уже реализован через аспект RolePermissionsServiceAspect.
4. Обратите внимание, что аспект RolePermissionsServiceAspect вступает в силу только тогда, когда значение Order транзакции больше 1. Если это стандартная транзакция (приоритет равен Integer.MAX_VALUE), то не нужно беспокоиться об этом значении. Однако если это пользовательская транзакция и установлено значение Order, то оно должно быть больше 1.

Временная диаграмма авторизации:

Диаграмма последовательности авторизации

Диаграмма времени обновления разрешений и обновления кэша разрешений в реальном времени:

![Обновление разрешений и обновление кэша разрешений в реальном времени](doc/RBAC%20Разрешение на обновление и разрешение на обновление в реальном времени.png)

Проверка подлинности:

— SMS-код: по умолчанию не реализован. — SmsCodeSender (https://gitee.com/pcore/UMS/blob/master/vc/src/main/java/top/dcenter/ums/security/core/api/validate/code/sms/SmsCodeSender.java)

— Изображение кода: реализована функция кэширования, поддерживается функция периодического обновления кэша, можно настроить путь вывода и количество кэшированных изображений кода. — ImageCodeFactory (https://gitee.com/pcore/UMS/blob/master/vc/src/main/java/top/dcenter/ums/security/core/api/validate/code/image/ImageCodeFactory.java)

— Код слайдера: реализована функция кэширования, поддерживается функция периодического обновления кэша, можно настроить путь вывода и количество кэшированных изображений кода, а также можно настроить исходный путь изображения и путь шаблона изображения (исходный путь изображения и путь шаблона изображения см. в примере проверки кода validate-code-example). — SimpleSliderCodeFactory (https://gitee.com/pcore/UMS/blob/master/vc/src/main/java/top/dcenter/ums/security/core/api/validate/code/slider/SliderCodeFactory.java)

— Пользовательский код: BaseAuthenticationSuccessHandler: обработчик успешной аутентификации.

BaseAuthenticationFailureHandler: обработчик неудачной аутентификации.

  1. Многопользовательская система:
  • TenantContextHolder: многопользовательский контекстный менеджер. После реализации этого интерфейса и внедрения в IOC-контейнер, компоненты регистрации/логина/авторизации UMS по умолчанию будут автоматически внедрены. Необходимо реализовать этот интерфейс и внедрить его в IOC-контейнер для обеспечения многопользовательской функциональности UMS.

    • Функции:

      1. tenantIdHandle(HttpServletRequest, String) извлекает tenantId из регистрационного пользовательского входа или входа в систему и выполняет необходимую логику (например, сохраняет tenantId в ThreadLocal, сеансе или кэше Redis).

      2. getTenantId() упрощает последующую обработку данных регистрации, входа и авторизации пользователей (например, добавление условия tenantId в SQL, добавление разрешения TENANT_tenantId при регистрации пользователя, получение разрешений ролей на основе tenantId).

      3. getTenantId(Authentication) — метод по умолчанию. Получает идентификатор арендатора от текущего пользователя после входа в систему, анализируя полномочия.

    • Примечание:

      1. В многопользовательской системе интерфейсы, требующие использования tenantId без входа в систему (например, UserCache.getUserFromCache(String)/UmsUserDetailsService), могут использовать getTenantId(). Пользователи, которые уже вошли в систему, могут получить tenantId через Authentication.

      2. Логика регистрации и входа по умолчанию в UMS включает tenantIdHandle(HttpServletRequest, String). Если вам нужно использовать tenantId при реализации интерфейсов, таких как UserCache/UmsUserDetailsService, вы можете вызвать метод getTenantId().

      3. Если у вас есть собственная логика регистрации или входа, сначала вызовите tenantIdHandle(HttpServletRequest, String), а затем вызовите getTenantId(), когда вам понадобится tenantId при реализации таких интерфейсов, как UserCache/UmsUserDetailsService.

  1. Интерфейс обработчика задач:
  • JobHandler: интерфейс обработчика задач. При наследовании этого интерфейса и внедрении в IOC-контейнер top.dcenter.ums.security.core.tasks.config.ScheduleAutoConfiguration будет автоматически зарегистрирован в ScheduledTaskRegistrar.
  1. JWT-интерфейс: см. jwt-example.

  2. Однократный вход (оператор):

  • OneClickLoginService: сервис однократного входа. Должен быть реализован. Получает номер телефона пользователя от оператора на основе accessToken.

Шесть, конфигурации:

Функция Модуль Пример модуля demo — простая конфигурация Пример модуля demo — подробная конфигурация
1. Основные функции core basic-example
2. Функция маршрутизации входа core basic-detail-example
3. Сеанс core session-detail-example
4. Запомнить меня core

通过下面的接口即可: HttpSecurityAware:

  • 已有的 HttpSecurity 配置, 让原有的 HttpSecurity 配置实现此接口进行配置: top.dcenter.security.core.api.config.HttpSecurityAware.
  1. С интеграцией spring cloud: 2020.0.0 и spring 2.4.x, из-за изменения способа загрузки конфигурационных файлов, при использовании spring.factories для загрузки этого класса, появляется следующее сообщение об ошибке: Found WebSecurityConfigurerAdapter as well as SecurityFilterChain. Please select just one.
  • Решение:
    • Первый вариант: использовать spring.factories для загрузки класса, а затем добавить пустой класс конфигурации WebSecurityConfigurerAdapter, чтобы предотвратить автоматическую загрузку Spring по умолчанию WebSecurityConfigurerAdapter конфигурации. Подходит для модулей, которые ввели top.dcenter:ums-core-spring-boot-starter или top.dcenter:ums-spring-boot-starter.
    @Configuration
    public class WebSecurityAutoConfigurer extends WebSecurityConfigurerAdapter { }
    • Второй вариант: не использовать spring.factories для загрузки класса, а напрямую зарегистрировать класс в контейнере IOC. Подходит для всех модулей.
    @Configuration
    public class WebSecurityAutoConfigurer {
        @Bean
        public SecurityCoreAutoConfigurer securityCoreAutoConfigurer() {
            return new SecurityCoreAutoConfigurer();
        }
    }

Перевод текста на русский язык:

Через следующий интерфейс можно: HttpSecurityAware — существующая конфигурация HttpSecurity, позволяет существующей конфигурации HttpSecurity реализовать этот интерфейс: top.dcenter.security.core.api.config.HttpSecurityAware.

  1. При интеграции с spring cloud версии 2020.0.0 и spring версии 2.4.х, из-за изменений в способе загрузки файлов конфигурации, при использовании spring.factories для загрузки данного класса возникает следующая ошибка: «Найден WebSecurityConfigurerAdapter и SecurityFilterChain. Пожалуйста, выберите только один». Решение:
  • Вариант первый: используйте spring.factories, чтобы загрузить класс, затем добавьте пустой класс конфигурации WebSecurityConfigurerAdapter, чтобы предотвратить автоматическую загрузку конфигурации WebSecurityConfigurerAdapter по умолчанию Spring. Подходит для модулей, в которых были введены top.dcenter:ums-core-spring-boot-starter или top.dcenter:ums-spring-boot-starter.
@Configuration
public class WebSecurityAutoConfigurer extends WebSecurityConfigurerAdapter { }.
  • Вариант второй: не используйте spring.factories для загрузки класса, вместо этого зарегистрируйте класс непосредственно в контейнере IOC. Подходит для всех модулей.
@Configuration
public class WebSecurityAutoConfigurer {
    @Bean
    public SecurityCoreAutoConfigurer securityCoreAutoConfigurer() {
        return new SecurityCoreAutoConfigurer();
    }
}
``` ## 12. Основываясь на механизме SLF4J MDC, функция отслеживания журнала

- Чтобы использовать эту функцию, добавьте `%X{MDC_TRACE_ID}` в шаблон `pattern` в файле конфигурации журнала.
```xml
<!-- Консоль -->
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <!-- Формат журнала -->
    <encoder>
        <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level ${PID:- } --- [%thread] %X{MDC_TRACE_ID} %logger[%L] - %msg%n</pattern>
        <charset>utf-8</charset>
    </encoder>
    <!-- Этот appender журнала предназначен для разработки и только настраивает самый низкий уровень, журналы с уровнем выше или равным этому уровню будут выводиться на консоль -->
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
        <!-- Только этот журнал имеет разрешение на просмотр, SQL-оператор -->
        <level>DEBUG</level>
    </filter>
</appender>
  • Определите тип идентификатора отслеживания журнала на основе SLF4J MDC с помощью свойства ums.mdc.type:
# Тип идентификатора отслеживания журнала, основанный на SLF4J MDC. По умолчанию используется uuid. Если необходимо настроить идентификатор, установите type = MdcIdType.CUSTOMIZE_ID и реализуйте метод MdcIdGenerator.getMdcId(), после чего внедрите его в контейнер IOC.
ums:
  mdc:
    type: UUID/THREAD_ID/SESSION_ID/CUSTOMIZE_ID

Если ums.mdc.type = CUSTOMIZE_ID, необходимо реализовать интерфейс MdcIdGeneratorMdcIdGenerator и внедрить его в контейнер IOC.

  • Проблемы с многопоточностью: перед созданием дочернего потока вызовите метод MDC.getCopyOfContextMap() родительского потока, чтобы получить контекст MDC. Перед выполнением операции в дочернем потоке вызовите MDC.setContextMap(context) и установите контекст родительского потока в дочерний поток. Конфигурацию ThreadPoolTaskExecutor см. в ScheduleAutoConfiguration.
  • Простой пример передачи контекста MDC между потоками:
final Logger log = LoggerFactory.getLogger(this.getClass());
// Получить содержимое MDC родительского потока
final Map<String, String> context = MDC.getCopyOfContextMap();
final Runnable r = () -> {
    log.info("testMDC");
    System.out.println("...");
};
new Thread(() -> {
    // Установить контекст MDC родительского потока в дочерний поток
    MDC.setContextMap(context);
    r.run();
}, "testMDC").start();
  • Поддержка передачи идентификаторов отслеживания журналов между микросервисами. При запросе к микросервису добавьте заголовок в запрос: headerKey=MDC_KEY, headerValue=MDC ID отслеживания журнала.

Ссылки

-Spring security JustAuth starter для реализации сторонней аутентификации

-Быстрый стартер для интеграции нескольких storage клиентов на основе aws s3

-JustAuth

Благодарности

Спасибо JetBrains за предоставление бесплатной версии IntelliJ IDEA Ultimate:

JetBrains

Комментарии ( 0 )

Вы можете оставить комментарий после Вход в систему

Введение

UMS — это настраиваемый каркас для управления пользователями, который не нарушает работу системы и имеет слабую связанность с бизнес-логикой. Интеграция: * аутентификация по паролю пользователя; * аутентификация через мобильный телефон; * однократная аутентификация; * поддержка всех видов сторонней аутентификации, поддерживаемой JustAuth; * вер... Развернуть Свернуть
MIT
Отмена

Обновления

Пока нет обновлений

Участники

все

Недавние действия

Загрузить больше
Больше нет результатов для загрузки
1
https://api.gitlife.ru/oschina-mirror/pcore-UMS.git
git@api.gitlife.ru:oschina-mirror/pcore-UMS.git
oschina-mirror
pcore-UMS
pcore-UMS
master