Как создать разные классы под разные роли в Spring Security?

Question

[Eugenue Cesarevich]

Для авторизации на основе ролей в приложении используется Spring Security, соответственно у меня есть сущность User с полем Set<Role> roles. Из-за того, что разным ролям нужны сильно различающиеся наборы полей, я хочу сделать User общим абстрактным классом и наследовать от него конкретные классы под каждую роль: SimpleUser, Admin и т.д.

Spring Security использует для авторизации UserDetailsServicе, вот моя имплементация:

@Service("securityUserService")
public class SecurityUserService implements UserDetailsService {

    private final UserRepository repository;

    public SecurityUserService(UserRepository repository) {
        this.repository = repository;
    }

    @Override
    public AuthorizedUser loadUserByUsername(String email) throws UsernameNotFoundException {
        User user = repository.getByEmail(email.toLowerCase());
        if (user == null) {
            throw new UsernameNotFoundException("User " + email + " is not found");
        }
        return new AuthorizedUser(user);
    }
}

Если у меня будет несколько разных сущностей для пользователей, значит мне надо сделать несколько разных таблиц. К этим таблицам надо будет сделать разные репозитории. Вот тут и возникают проблемы. Если, допустим, авторизуется админ, то откуда сервис знает, в каком репозитории ему искать этого пользователя, если он знает только его имя?

Как мне правильно сделать так, чтобы у каждой роли был свой класс пользователя?

Answer 1

[Максим Федоров]

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

разным ролям нужны сильно различающиеся наборы полей

Не нужно, это др сущности (абстракции), а для проверки роли и авторизационных кредденшнлов вам достаточно класса User

Дальше уже работайте со своими админами (Admin), покупателями (Customer) и прочее, у которых только будет userId и только... То есть сервис по работе с покупателем будет с ним и работать, а попадет исполнение кода туда, когда вы вызовете метод контроллера, который с этой логикой и работает, и перед этим спросит права у юзера :)

User — это про права и роли, потому абстрактно так и называется он :)

Comments

[Eugenue Cesarevich]

хм, я правильно понимаю, что вы предлагаете вообще разделить User для авторизации и User для держания полей? Как-то не думал над этим. Только надо будет как-то их соединять друг с другом... При помощи fk наверное

Answer 2

[Орхан Гасанлы]

Я бы не создавал классы для каждой из роли, а реализовал бы следующим образом:
1) Создать класс User. Пометить @MappedSuperclass. Вынести туда общие поля: username, password и др.
2) Далее создать нужные классы и расширить класс User. Например, Customer, Author и др. И все поля специфичные для каждого из классов указать в них.
3) Далее можно например, создать паттерн Builder, который при создание сущности по дефолту будет назначать соответствующие классу роли.

P.S. Не забудьте также имплементировать интерфейс UserDetails нужный для Spring Security.

Comments

[Eugenue Cesarevich]

Но всё-таки получается, что для каждой роли свой класс. Или я чего-то не догоняю? В принципе, я так и решил сделать.

[Орхан Гасанлы]

Eugenue Cesarevich, ну по идее да. Тут уже как настроите. У каждого класса может быть и одна роль или сет ролей.