Spring Security – Configuring Different URLs

1. Overview

In this tutorial, we’ll look at how to configure Spring Security to use different security configurations for different URL patterns.

This is helpful when an application requires more security for certain operations while others are permitted for all users.

2. Setup

Let’s start by setting up the application.

We’ll need the Web and Security dependencies to create this service. Let’s start by adding the following dependencies to the pom.xml file:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<dependency> 
    <groupId>org.springframework.boot</groupId> 
    <artifactId>spring-boot-starter-security</artifactId> 
</dependency> 

3. Create the APIs

We’ll create a RESTful web service with two APIs: a Product API and a Customer API. To achieve this, we’re going to set up two controllers.

3.1. Product API

Let’s create the ProductController. It contains a single method, getProducts, which returns a list of products:

@RestController("/products")
public class ProductController {
    
    @GetMapping
    public List<Product> getProducts() {
        return new ArrayList<>(Arrays.asList(
          new Product("Product 1", "Description 1", 1.0),
          new Product("Product 2", "Description 2", 2.0)
        ));
    }
}

3.2. Customer API

Similarly, let’s define the CustomerController: 

@RestController("/customers")
public class CustomerController {
    
    @GetMapping("/{id}")
    public Customer getCustomerById(@PathVariable("id") String id) {
        return new Customer("Customer 1", "Address 1", "Phone 1");
    }
}

In a typical web application, all users, including guest users can get a list of products.

However, getting a customer’s detail by their ID seems like something only an admin can do. So we’ll define our security configuration in a way that can enable this.

4. Set Up the Security Configuration

When we add Spring Security to the project, it will disable access to all APIs by default. So we’ll need to configure Spring Security to allow access to the APIs.

Let’s create the SecurityConfiguration class:

@Configuration
public class SecurityConfiguration {

     @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        return http.authorizeHttpRequests(request -> request.requestMatchers(new AntPathRequestMatcher("/products/**"))
                .permitAll())
            .authorizeHttpRequests(request -> request.requestMatchers(new AntPathRequestMatcher("/customers/**"))
                .hasRole("ADMIN")
                .anyRequest()
                .authenticated())
            .httpBasic(Customizer.withDefaults())
            .build();
    }
}

Here, we’ve created a SecurityFilterChain bean to configure the security for the application.

Additionally, to prepare for basic authentication, we need to configure users for our application.

We’ll read each part of the code to understand it better.

4.1. Allowing Requests to the Products API

• authorizeRequests(): This method tells Spring to use the following rules while authorizing requests.
• antMatchers(“/products/**”): This specifies the URL patterns for which the security configuration applies. We are chaining it with a permitAll() action. If a request contains “/products” in its path, it is allowed to go to the controller.
• We can add more rules to our configuration using the and() method.

This marks the end of one chain of rules. The other rules which follow will also be applied to the requests. So we need to make sure our rules do not conflict with each other. A good practice is to define generic rules at the top and more specific rules at the bottom.

4.2. Allow Only Admin Access to the Customer API

Now let’s look at the second part of the configuration:

• To start a new rule, we can once again use the authorizeRequests() method.
• antMatchers(“/customers/**”).hasRole(“ADMIN”): If the URL contains “/customers” in the path, we check that the user making the request has the role ADMIN.

If the user is not authenticated, this will lead to a “401 Unauthorized” error. If the user does not have the correct role, this will lead to a “403 Forbidden” error.

4.3. Default Rule

We have added matches to match certain requests. Now we need to define some default behavior for the rest of the requests.

anyRequest().authenticated() – anyRequest() defines a rule chain for any request which did not match the previous rules. In our case, such requests will be passed as long as they are authenticated.

Please note that there can be only one default rule in the configuration, and it needs to be at the end. If we try to add a rule after adding a default rule, we get an error – “Can’t configure antMatchers after anyRequest”.

5. Testing

Let’s test both APIs using cURL.

5.1. Test the Product API

$ curl -i http://localhost:8080/products
[
  {
    "name": "Product 1",
    "description": "Description 1",
    "price": 1.0
  },
  {
    "name": "Product 2",
    "description": "Description 2",
    "price": 2.0
  }
]

We get the two products in response as expected.

5.2. Test the Customer API

$ curl -i http://localhost:8080/customers/1

The response body is empty.

If we check the header, we’ll see “401 Unauthorized” status. This is because access to the Customer API is only allowed for authenticated users with the role ADMIN.

Now let’s try again after adding authentication information to the request:

$ curl -u admin:password -i http://localhost:8080/customers/1 
{
  "name": "Customer 1",
  "address": "Address 1",
  "phone": "Phone 1"
}

Great! We can now access the Customer API.

6. Conclusion

In this tutorial, we learned how to set up Spring Security in a Spring Boot application. We also covered configuring access specific to a URL pattern using the antMatchers() method.