Управление пользователями UMS: каркас для разработки

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

UMS — это ненавязчивый каркас для управления пользователями с высокой степенью развязки от бизнес-логики, который можно настраивать.

Каркас для управления пользователями, интеграция: вход по паролю пользователя, мобильный вход, вход OAuth2 (на основе JustAuth), однократный вход, поддержка мультиарендности, JWT, проверка кода (изображение, SMS, ползунок), RBAC, SLF4J-MDC, подпись и т. д.

1. Основные функции UMS:

• функция проверки кода (изображения, SMS, слайдера).
• Функция мобильного входа, автоматическая регистрация после входа в систему, поддержка мультитенантности.
• Поддержка всех сторонних авторизованных логинов, поддерживаемых JustAuth, после входа автоматически регистрирует или привязывает или создаёт временных пользователей (TemporaryUser).
  • Поддерживает функцию автоматического обновления accessToken, поддерживает распределённые задачи синхронизации.
  • Поддерживает функцию кэширования пользовательской таблицы и таблицы токенов при входе через OAuth2.
  • Поддерживает интерфейсы привязки и отмены привязки и запросов третьих сторон.
• Однократный вход.
• Функция контроля доступа, поддержка мультиарендности.
• Упрощение конфигурации сеанса, запоминания меня, csrf cors и т.д.
• Возврат данных JSON или HTML в соответствии с установленным методом ответа (JSON и REDIRECT).
• Подпись.
• Поддерживает функцию отслеживания ссылок на основе механизма SLF4J MDC.
• Создание JWT, верификация, обновление, проблемы параллельного доступа из-за недействительности JWT и функции чёрного списка.

Функции модулей

• UmsUserDetailsService.

2. Контроль доступа на основе RBAC: поддержка мультиарендности.

   • UriAuthorizeService: Рекомендуется реализовать интерфейс AbstractUriAuthorizeService для реализации этого интерфейса.

   • AbstractUriAuthorizeService: Должен быть реализован (Must implemente).

     • uri (ресурс) сервис контроля доступа к правам на основе (роль / мультиарендность / SCOPE), определяющий логику контроля доступа на основе ролей / мультиарендности / SCOPE. Реализуйте абстрактный класс AbstractUriAuthorizeService и внедрите его в IOC-контейнер, чтобы заменить DefaultUriAuthorizeService.

     • Обратите внимание:

       1. Рекомендуется реализовать AbstractUriAuthorizeService одновременно с реализацией UpdateCacheOfRolesResourcesService для обновления и кэширования сервиса разрешений, что может помочь повысить производительность службы авторизации.

       2. Требования к входящим полномочиям Authentication являются жёсткими:

       // Эти полномочия могут включать: [ROLE_A, ROLE_B, ROLE_xxx TENANT_110110, SCOPE_read, SCOPE_write, SCOPE_xxx]
       // Требования к полномочиям:
       //    1. Количество ролей >= 0
       //    2. Количество SCOPE >= 0
       //    3. Количество мультитенантов 1 или 0
       //    4. Количество ролей + количество SCOPE >= 1
       Collection<? extends GrantedAuthority> authorities = authentication.getAuthorities();

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

   • UpdateCacheOfRolesResourcesService:

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

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

       1. На основе контроля разрешений ролей: реализуйте обновление и кеширование разрешений всех ролей для всех uri (ресурсов) в локальной памяти.

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

       3. На основе контроля разрешений мультиарендности: ситуация более сложная, и если мультиарендных арендаторов мало, то все разрешения также могут быть полностью кэшированы в локальной памяти. В большинстве случаев полное кеширование в локальной памяти невозможно, и можно использовать только такие механизмы кеширования, как redis.

   • RolePermissionsService:

     • Обновляет и запрашивает сервисы разрешений на основе (ролей / мультиаренд / SCOPE). В основном используется для добавления операций с разрешениями ролей.

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

       1. При добавлении ресурсов используйте PermissionType.getPermission() для стандартизации формата разрешений, поскольку необходимо поддерживать restful API, а при авторизации необходимо сопоставить HttpMethod с соответствующим разрешением.

       2. Если вы реализуете интерфейс UpdateCacheOfRolesResourcesService, но не реализуете RolePermissionsService, при изменении или добавлении разрешений ресурсов на основе «ролей / мультиаренд / SCOPE» обязательно вызовите соответствующий метод UpdateCacheOfRolesResourcesService. Есть два способа: один — опубликовать событие, другой — напрямую вызвать соответствующий сервис. UpdateCacheOfRolesResourcesService.updateRolesByGroupIdOfTenant(tenantId, groupId, roleIds)

3. Реализовать интерфейс RolePermissionsService, не требуется выполнять операции двух предыдущих методов. Публикация события UpdateRolesResourcesEvent реализована через AOP.

4. Внимание: условие для того, чтобы аспект RolePermissionsServiceAspect вступил в силу — значение Order в транзакции должно быть больше 1. Если это стандартная транзакция (приоритет равен Integer.MAX_VALUE), то беспокоиться об этом значении не нужно. Если же это пользовательская транзакция и задано значение Order, то оно должно быть больше 1.

Проверка кода (ValidateCode)

— SMS-код проверки: реализация по умолчанию отсутствует. — SmsCodeSender.

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

— Код проверки с ползунком: реализована функция кэширования, поддерживается функция периодического обновления кэша, можно настроить пути вывода и количества изображений кэша; поддерживается настройка исходного изображения и пути шаблона изображения (исходное изображение и шаблон изображения см. в validate-code-example). — SimpleSliderCodeFactory.

— Пользовательский код проверки: — AbstractValidateCodeProcessor. — ValidateCodeGenerator.

OAuth2

— Настроить кодирование и декодирование состояния в процессе OAuth2. Можно передавать необходимую информацию, например, адрес перехода после успешного входа в систему от стороннего поставщика услуг. — Auth2StateCoder: необходимо реализовать пользователю. Кодирует и декодирует состояние в процессе авторизации от стороннего провайдера. Можно передать необходимую информацию, такую как адрес перехода после успешной авторизации от стороннего провайдера услуг. Обратите внимание, что оба метода этого интерфейса должны реализовывать соответствующую логику кодирования и декодирования. После реализации интерфейса его необходимо внедрить в IOC-контейнер. Если есть необходимость получить параметр authorizeUrl от внешнего интерфейса, а затем передать дополнительную информацию на сервер во время регистрации, необходимо реализовать этот интерфейс вместе с методом UmsUserDetailsService.registerUser(AuthUser, String, String, String).

— Получить информацию о пользователе от стороннего поставщика услуг: — Auth2UserService: обычно не требует реализации пользователем, если только не требуется настроить получение информации о пользователе. Внедрить в IOC-контейнер после реализации.

— Регистрация, привязка и обновление информации о пользователях от сторонних поставщиков услуг и информации о токенах доступа: — ConnectionService: регистрация, привязка, обновление информации о сторонних пользователях и токенов доступа. Обычно не требует реализации, за исключением случаев, когда требуется настроить процесс получения информации о пользователях. Внедрить в IOC-контейнер после реализации. Необходимо отключить автоматическое создание таблиц auth_token и user_connection при запуске приложения, установив свойство ums.repository.enableStartUpInitializeTable = false.

— UsersConnectionRepository: интерфейс для добавления, удаления, изменения и запроса информации о пользователях сторонних провайдеров, привязки и отвязки, а также проверки привязки и отвязки. Обычно не требует реализации. Внедрить в IOC-контейнер после реализации, если требуется настроить получение информации о пользователях.

— UsersConnectionTokenRepository: интерфейс для запроса, добавления, удаления и изменения информации о токене доступа. Обычно не требует реализации. Внедрить в IOC-контейнер после реализации, если требуется настроить получение информации о пользователях. | **Модуль (model)**                                                 | **demo модуль — простая конфигурация (Simple Configuration)**                                       | **demo модуль — подробная конфигурация (detail Configuration)**                                      |

| ------------------------------------------------------------ | -------------------------------------------------------- | ------------------------------------------------------------| | 1. Основные функции | core | basic-example | | 2. Функции маршрутизации входа | core | | basic-detail-example| | 3. Session | core | | session-detail-example| | 4. Remember-me | core | | basic-detail-example| | 5. CSRF | core | | basic-detail-example| | 6. Anonymous | core | | basic-detail-example| | 7. Проверка кода | core | | validate-code-example| | 8. Вход с мобильного устройства | core | | basic-detail-example| | 9. Сторонний вход | core | | basic-detail-example| | 10. Добавление таблиц user_connection и auth_token в базу данных redis для использования при стороннем входе | | | Внимание: данный ответ не является профессиональным переводом, так как в запросе отсутствует текст.

Семь. Примечание (NOTE):

1. Проблемы конфигурации HttpSecurity: проблема конфликта конфигурации HttpSecurityAware в UMS и конфигурации HttpSecurity в приложении:

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

2. В сочетании с 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();
    }
}

Схема логической последовательности конфигурации безопасности:

2. Свойства, хранящиеся в ServletContext: — Имя свойства: SecurityConstants.SERVLET_CONTEXT_PERMIT_ALL_SET_KEY. Свойства: Set Значение: Хранится в servletContext набор типов разрешений PERMIT_ALL.

4. Приоритет кода подтверждения (Verification code Priority):

• Для одного и того же URI можно настроить несколько кодов подтверждения, приоритет которых следующий: SMS > CUSTOMIZE > SELECTION > TRACK > SLIDER > IMAGE

5. Сериализация и десериализация Jackson

• Добавить десериализаторы для некоторых подклассов Authentication и UserDetails, чтобы решить проблему невозможности десериализации этого типа из кеша Redis. Конкретные настройки десериализатора Redis см. в методе RedisCacheAutoConfiguration.getJackson2JsonRedisSerializer().

// Пример
Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
ObjectMapper objectMapper = new ObjectMapper();
// Auth2Jackson2Module — это конфигурация десериализации, реализованная в этом проекте
objectMapper.registerModules(new CoreJackson2Module(), new WebJackson2Module(), new Auth2Jackson2Module());
jackson2JsonRedisSerializer.setObjectMapper(om);

• Обратите внимание: метод UmsUserDetailsService.registerUser() возвращает UserDetails по умолчанию, который уже реализовал десериализатор. Если это пользовательский подкласс, то разработчик должен сам реализовать десериализатор.

Восемь. Конфигурации свойств (Properties Configurations)

Девять. Участие в разработке (Participate in contribution)

1. Fork этот проект.
2. Создать ветку Feat_xxx.
3. Отправить код.
4. Создать Pull Request.

Десять. Блок-схемы (Flow chart)

Блок-схема входа (Login Flow chart)

Блок-схемы JWT

• Чистая JWT (Pure JWT flow chart)

• JWT с сессией (JWT with session flow chart)

Блок-схема слайдера проверки кода (Slider verification code Flow chart)

Одиннадцать. Диаграммы последовательности (Sequence Diagram)

• Чтобы использовать эту функцию, добавьте %X{MDC_TRACE_ID} в шаблон конфигурации журнала.

<!-- Консоль -->
<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>

• Для реализации пользовательского типа идентификатора MDC на основе 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.setContextMap(context);
    r.run();
}, "testMDC").start();

• Поддержка передачи идентификатора отслеживания журналов между микросервисами, при запросе к микросервису добавьте в заголовок запроса: headerKey=MDC_KEY, headerValue=Идентификатор отслеживания журнала MDC.

Ссылки

• Шаблон проекта Spring security для интеграции JustAuth для реализации авторизации от третьих лиц

• Стартер для быстрой интеграции нескольких storage client на основе aws s3

• JustAuth

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

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