default-configuration

By default Spring security framework protects all the paths present inside the web application

This behavior is due to the code present inside the method defaultSecurityFilterChain(HttpSecurity http) of class SpringBootWebSecurityConfiguration

@Bean
@Order(SecurityProperties.BASIC_AUTH_ORDER)
SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http) throws Exception{
    http.authorizeHttpRequests().anyRequest().authenticated();
    http.formLogin();
    http.httpBasic();
    return http.build();
}

The default configuration for web security, it relies on Spring Security content-negotiation strategy to determine what sort of authentication to use.

If the user specifies their own SecurityFilteChain bean, this will back-off completely and the usres should specify all the bits that they want to configure as part of the custom security configuration

All the custom requirements for url validations, you need to invoke a method called, requestMatchers, this will accept any number of api paths separated by comma and invoke authenticated() to authenticate user if they are accessing these api calls or invoke permitAll() method to give access to everyone

Example:


@Bean
SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(
            (requests) -> requests.requestMatchers("/myAccount","/myBalance","/myLoans","/myCards").authenticated()
                                .requestMatchers("/notices","/contact").permitAll())
        .formLogin(Customizer.withDefaults())
        .httpBasic(Customizer.withDefaults());

    return http.build();
}

We can also mention the regex patterns from api endpoints

If you use /myAccount/** -> this means consider all endpoints that starts with /myAccount

User Management Services

UserDetailsService (Interface) -> code interface which loads user-specific data
UserDetailsManager (Interface) -> an extension of the userDetailsService which provides the ability to create new users and update existing ones
1. InMemoryUserDetailsManager
2. JdbcUserDetailsManager
3. LdapUserDetailsManager
These sub three classes are sample implementation classes provided by the spring security team

All the above classes and interfaces uses an interface UserDetails and its implementation which provides the core user information

Regarding the UserDetails object, there are no setter methods, which mean that once the object is created there is no option to update the details of the user directly

Spring Security deals with UserDetails and Authentication separately, hence there are two different implementations you will see in which methods and its implementations are same. But the fuctionalities of why they are created are different

Authentication is the return type in all the scenarios where we are tyring to determine if the authentication is successful or not. Example classes include, AuthenticationProvider and AuthenticationManager

Similarlly, UserDetails is the return type in all the scenarios where we try to load the user info from the database systems or from inMemoryStorage Example classes include, UserDetailsService and UserDetailsManager

How Passwords are validated with default PasswordEncoder

Encoding vs Encryption vs Hashing

Details of PasswordEncoder

public interface PasswordEncoder{
    String encode(CharSequence rawPassword);
    boolean matches(CharSequence rawPassword, String encodedPassword);
    default boolean upgradeEncoding(String encodedPassword){ return false;}
}

Authentication Providers in Spring Security

The AuthenticationProvider in spring security takes care of the authentication logic. The default implementation of the AuthenticationProvider is to deligate the responsibility of finding the user in the system to a UserDetails implementation and PasswordEncoder for password validation. But if we have a custom authentication requirement that is not fulfilled by Spring Security framework, then we can build our own authentication logic by implementing the AuthenticationProvider interface

It is the responsibility of the ProviderManager which is an implementation of AuthenticationManager to check with all the implementations of Authentication Providers and try to authenticate the user.

Details of AuthenticationProvider

public interface AuthenticationProvider{
    Authentication authenticate(Authentication authentication) throws AuthenticationException;
    boolean supports(Class<?> authentication);
}

authenticate() method receives and returns the authentication object, we can implement our custom authentication logic in this authenticate() method

The second method in the AuthenticateProvider interface is supports(Class<?> authentication) You will implement this method to return true if the current authentication provider supports the type of the authentication object provided

If the AuthenticationProvider is unable to support authentication of the passed Authentication object, In such case, the next AuthenticationProvider that supports the presented Authentication class will be tried

Once the user is authenticated successfully, then there is no need for storing user credentials in the authentication object, hence after the auth is successful, ProviderManager erases the credentials from authentication object by invoking the method eraseCredentialsAfterAuthentication

CROS & CSRF

CORS - CROSS ORIGIN RESOURCE SHARING CSRF - CROSS SITE REQUEST FORGERY

CORS is a protocol that enables scripts running on a browser client to interact with resources form a different origin. For example, if a UI app wishes to make an API call running on a different domain, it would be blocked from doing so by default due to CORS. It is a specification from W3C implemented by most browsers

other origins means the URL being accessed differs from the locatoin that the javascript is running from, by having 1. a different scheme (HTTP or HTTPS) 2. a different domain 3. a different port

Handling CORS issue

if we have a scenario where frontend part is trying to connect with REST service deployed on another server, then these kind of communications we can allow with the help of @CrossOrigin annotation

@CrossOrigin allows clients from any domain to consume the API

@CrossOrigin(origins="http://localhost:4200") //allow requests from only specified domains

@CrossOrigin(origins="*") // allow requests from all domains

Preflight Request:

A CORS preflight request is a CORS request that checks to see if the CORS protocol is understood and a server is aware using specific methods and headers

It is an "OPTIONS" request, using two or three HTTP request headers:

Access-Control-Request-Method
Origin
Access-Control-Request-Headers

A preflight request is automatically issued by a browser and in normal cases, front-end developers dont need to craft such requests themselves. It appears when request is qualified as "to be preflighted" and omitted for simple requests

This CORS security feature we can also configure using spring-security configurations instead of annotating all the controllers in our application


@Bean
SecurityFilterChain defaultFilterChain(HttpSecurity http) throws Exception{
    http.cros().configurationSource(new CorsCOnfigurationSource(){
        @Override
        public CorsConfiguration getCorsConfiguration(HttpServletRequest request){
            CorsConfiguration config = new CorsConfiguration();
            config.setAllowedOrigins(Collections.singletonList("http://localhost:4200"));
            config.setAllowedMethods(Collections.singletonList("*"));
            config.setAllowCredentials(true);
            config.setAllowedHeaders(Collections.singletonList("*"));
            config.setMaxAge(3600L);
            return config;
        }
    }).authorizeHttpRequests()
    .requestMatchers().authenticated()
    .requestMatchers().permitAll()
    .requestMatchers().denyAll()
    .formLogin()
    .httpBasic()
    .build()

    return http;
}

Typical Cross-site Request Forgery attack aims to perform an operation in a web application on behalf of a user without their explicit consent. In general, it doesnt directly steal the users identity, but it exploits the user to carry out an action without their will

PreviousSpring-Security NextTypeScript

Last updated 1 year ago

@Bean @Order(SecurityProperties.BASIC_AUTH_ORDER) SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http) throws Exception{ http.authorizeHttpRequests().anyRequest().authenticated(); http.formLogin(); http.httpBasic(); return http.build(); }

@Bean SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http) throws Exception { http.authorizeHttpRequests( (requests) -> requests.requestMatchers("/myAccount","/myBalance","/myLoans","/myCards").authenticated() .requestMatchers("/notices","/contact").permitAll()) .formLogin(Customizer.withDefaults()) .httpBasic(Customizer.withDefaults()); return http.build(); }

public interface PasswordEncoder{ String encode(CharSequence rawPassword); boolean matches(CharSequence rawPassword, String encodedPassword); default boolean upgradeEncoding(String encodedPassword){ return false;} }

@Bean SecurityFilterChain defaultFilterChain(HttpSecurity http) throws Exception{ http.cros().configurationSource(new CorsCOnfigurationSource(){ @Override public CorsConfiguration getCorsConfiguration(HttpServletRequest request){ CorsConfiguration config = new CorsConfiguration(); config.setAllowedOrigins(Collections.singletonList("http://localhost:4200")); config.setAllowedMethods(Collections.singletonList("*")); config.setAllowCredentials(true); config.setAllowedHeaders(Collections.singletonList("*")); config.setMaxAge(3600L); return config; } }).authorizeHttpRequests() .requestMatchers().authenticated() .requestMatchers().permitAll() .requestMatchers().denyAll() .formLogin() .httpBasic() .build() return http; }