Spring Security - Para que ele foi projetado?

1) Como o spring security espera que minhas tabelas estejam mapeadas? => Ele não espera :). Tudo é baseado em interfaces, então você decide como quer criar suas tabelas.

1.1) Posso ter usuario e senha em 2 tabelas? Sim. Só que a query resultando precisa retornar um UserDetails como tudo.

1.2) Para um caso de usuario Administrador e Consumidor, com atributos diferentes, porém com os atributos de autenticação iguais (login, senha e permissoes), eu devo criar 3 tabelas? Nesse caso você realmente precisa de entidades diferentes e talvez até dois fluxos diferentes de login.

1.2.1) Todos os objetos devem implementar userDetails? Sim.

1.2.2) Existe alguma forma de manter em cada tabela um usuario e senha e de acordo com o login ele buscar? Na doc encontrei isso (https://docs.spring.io/spring-security/site/docs/5.0.0.RC1/reference/htmlsingle/#multiple-httpsecurity) Mas implementando e para o meu caso ele não funcionou. Ou ele permitia acesso a tudo, ou nada. => Aqui entra a resposta anterior, é melhor que seja dois fluxos diferentes de autenticação.

Olá Alberto,

Obrigado pela sua resposta.

Para esse caso acima, você poderia me ajudar? Porque tudo que procuro, nada funciona!

Pior que não tenho nenhum exemplo. Configuraria duas entradas do spring security, apontando URLs de login diferentes. E teria tudo meio que duplicado, menos a classe que representa a role.

Pois bem alberto, eu fiz isso.

Quando eu defino @Order(1) e @Order(2) somente uma delas funciona.

Se eu quisesse por exemplo restringir somete /admin/** para usuarios Admininstradores e o resto gostaria de autenticar somente os usuários consumidores, ele não entende e não permite autenticar

Alberto, baseado nesse meu problema, gostaria que julgasse a solução que encontrei:

1) Criei uma tabela com os dados que eram comum como, permissao, login e senha.

2) Criei uma tabela administradores com os dados a mais, e com um objeto referenciando o usuario de cima.

3) Fiz a mesma coisa para os consumidores

4) Na minha implementação de loadUserByUsername eu descubro o tipo dele e busco o objeto. Como ambos implementam userDetails eu posso fazer polimorfismo, e então tenho meu usuário autenticado independente do tipo de perfil.