I have following issue.

I have multitenant system (with shared Database and shared Schema). Access token that is generated when user logs in contains information about tenantId. Idea is to allow logged user to change tenat

For example: My user works for 3 tenants(hospitals). When he is logged in, he should be able to change hospital.

So the main issues is how to generate new acces token for user that will contain updated tenantId. It would be preferable that user doesnt have to provide password again (since he is already logged in), and that request to auth-server that he triggers would contain his current token (that will confirm that he is currently authenticated) and newTenandId.

Here is some custom code:

@Service
public class CustomAuthenticationProvider implements AuthenticationProvider {
    
    @Autowired
    private MessageSource validationMessageSource;
    
    @Autowired
    private UserDetailsService userDetailsService;
    
    @Autowired
    private PasswordEncoder passwordEncoder;
    
    @Override
    public Authentication authenticate(Authentication authentication) throws AuthenticationException {
        String username = authentication.getName();
        String password = authentication.getCredentials().toString();
        
        SpringSecurityUserWithAdditionalData user = (SpringSecurityUserWithAdditionalData) userDetailsService.loadUserByUsername(username);
        
        return checkPassword(user, password);
    }
    
    @Override
    public boolean supports(Class<?> authentication) {
        return authentication.equals(UsernamePasswordAuthenticationToken.class);
    }
    
    private Authentication checkPassword(SpringSecurityUserWithAdditionalData user, String rawPassword) throws AuthenticationException {
        try {
            if (passwordEncoder.matches(rawPassword, user.getPassword())) {
                
                UsernamePasswordAuthenticationToken token = new UsernamePasswordAuthenticationToken(user.getUsername(), user.getPassword(), user.getAuthorities());
                
                return token;
            } else {
                throw new GeneralException(validationMessageSource.getMessage("security.authentication.NotValid", new Object[] {}, LocaleContextHolder.getLocaleContext().getLocale()));
            }
        } catch (Exception e) {
            throw new BadCredentialsException(e.getMessage());
        }
        
    }
    
}

@Configuration
@EnableWebSecurity
public class WebSecurityConfiguration {
    
    @Autowired
    private CustomAuthenticationProvider authenticationProvider;
    
    // @formatter:off 
    @Bean
    SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http) throws Exception {
        http
            ...
            .and()
                .logout()
                .clearAuthentication(true)
                .invalidateHttpSession(true)
                .deleteCookies("JSESSIONID")
                .logoutSuccessHandler(new CustomLogoutSuccessHandler())
            .and()
                .formLogin()
                .loginPage("/login")
                .loginPage("/changeTenant")
                .permitAll().and();
        return http.build();
    }
    // @formatter:on
    
    @Bean
    public PasswordEncoder passwordEncoder() {
        return PasswordEncoderFactories.createDelegatingPasswordEncoder();
    }
    
    @Autowired
    public void configureAuthentication(AuthenticationManagerBuilder auth) throws Exception {
        auth.authenticationProvider(authenticationProvider);
    }
    
    /**
     * JWT koji je generisao authorization server sadrzi granted permissions (Spring ih naziva granted authorities) u okviru "scope" claim-a. 
     * Umesto njega cemo koristiti custom claim koji sam nazvao GlobalConstants.JWT_CLAIM_ROLA_LIST za specifikaciju rola koje ima authenticated korisnik.
     * Spring koristi default instance JwtAuthenticationConverter koja ocekuje granted authorities u okviru "scope"/"scp" claim-a. 
     * Da bi koristili umesto standardno "scope" claim-a koristili claim GlobalConstants.JWT_CLAIM_ROLA_LIST override-ovan je JwtAuthenticationConverter.
     */
    @Bean
    public JwtAuthenticationConverter jwtAuthenticationConverter() {
        JwtGrantedAuthoritiesConverter converter = new JwtGrantedAuthoritiesConverter();
        converter.setAuthoritiesClaimName(GlobalConstants.JWT_CLAIM_ROLA_LIST); // override authorities claim-a
        converter.setAuthorityPrefix(""); // eksplicitno definisemo nazive, bez podrazumevanih prefiksa (ROLE_ SCOPE_ i slicno)
        
        JwtAuthenticationConverter jwtConverter = new JwtAuthenticationConverter();
        jwtConverter.setJwtGrantedAuthoritiesConverter(converter);
        return jwtConverter;
    }
    
    @Bean
    InitializingBean forcePostProcessor(BeanPostProcessor meterRegistryPostProcessor, MeterRegistry registry) {
        return () -> meterRegistryPostProcessor.postProcessAfterInitialization(registry, "");
    }
    
}

If you need any additional information, please say.

I tried adding custom fields to custom login form, that will have hidden tenantId field. But i could not manage to make it work.

CodePudding user response：

The authentication process should be designed to return a list of all the tenants the user has access to, typically as a list of authorities.

Separately you need a back-end call (linked to the UI) that allows the user to choose the current tenant from the list of authorities returned in authn.

The value of the current tenant must be stored in the session.

CodePudding user response：

If you really want to hack this via the auth roles, you could store the real auth token and generate your own token with only the current tenant. When user changes tenant they get a new token with the new tenant (obviously after checking against the real token)