Intro to Spring Security Expressions

1. Introduction

In this tutorial, we’ll focus on Spring Security Expressions and practical examples using these expressions. Spring Security Expressions provide a way to define authorization rules in a declarative manner.

They allow for flexibility when specifying who can access specific URLs or execute certain methods. These expressions are crucial for handling security at various levels in our application, from web request authorization to method-level security.

Before looking at more complex implementations, such as ACL, it’s important to have a solid grasp on security expressions, as they can be quite flexible and powerful if used correctly.

2. Maven Dependencies

To use Spring Security in our project, we include the following dependencies in the pom.xml:

<dependencies>
    <dependency>
        <groupId>org.springframework.security</groupId>
        <artifactId>spring-security-web</artifactId>
        <version>6.1.5</version>
   </dependency>
</dependencies>

The spring-security-web dependency is essential for Spring Security, while spring-core and spring-context are required for a fully functional web application.

3. Configuration

Spring Security can be configured using Java-based configuration, which offers better flexibility and is the recommended approach in most modern Spring applications. Below is an example:

@Configuration
@EnableWebSecurity
@EnableGlobalMethodSecurity(prePostEnabled = true)
@ComponentScan("com.baeldung.security")
public class SecurityJavaConfig {
    ...
}

The @EnableGlobalMethodSecurity(prePostEnabled = true) annotation enables the use of @PreAuthorize and @PostAuthorize annotations, allowing for method-level security. With these annotations, we can apply security logic before or after a method executes.

4. Web Security Expressions

Let’s dive into some common Spring Security expressions:

4.1. hasRole(), hasAnyRole()

These expressions are used to specify which roles are required to access specific URLs or methods:

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    return http
      .antMatchers("/auth/admin/*").hasRole("ADMIN")
      .antMatchers("/auth/*").hasAnyRole("ADMIN", "USER")
      .build();
}

The above example ensures that only users with the ADMIN role can access URLs starting with /auth/admin/, while both ADMIN and USER roles are allowed access to URLs starting with /auth/.

4.2. hasAuthority(), hasAnyAuthority()

Roles and authorities are both used for access control, but they have slightly different semantics. Authorities don’t require the ROLE_ prefix, which Spring adds automatically for roles. Using authorities instead of roles is recommended, as it allows more flexibility.

Here’s a quick example of defining users with specific authorities:

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    return http
      .authorizeHttpRequests(auth -> auth
        .requestMatchers("/auth/admin/*").hasAuthority("ADMIN")
        .requestMatchers("/auth/*").hasAnyAuthority("ADMIN", "USER"
      )
      .build();
}

4.3. permitAll(), denyAll()

These expressions allow us to explicitly permit or deny access to specific URLs. Let’s have a look at the example:

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    return http
      .authorizeHttpRequests(auth -> auth
        .requestMatchers("/public/**").permitAll()
        .requestMatchers("/private/**").denyAll()
      )
      .build();
}

This configuration uses permitAll() to allow anyone to access URLs starting with /public/, making them publicly available, while denyAll() completely blocks access to URLs beginning with /private/, effectively disabling those resources.

4.4. isAnonymous(), isRememberMe(), isAuthenticated(), isFullyAuthenticated()

These expressions control access based on the user’s authentication status:

• isAnonymous(): Allows access to unauthenticated users.
• isAuthenticated(): Restricts access to authenticated users.
• isFullyAuthenticated(): Requires users to re-authenticate for sensitive operations.
• isRememberMe(): Allows access to users authenticated via “remember-me” functionality.

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    return http
      .authorizeHttpRequests(auth -> auth
        .requestMatchers("/login").anonymous()
        .requestMatchers("/dashboard").authenticated()
        .requestMatchers("/settings").fullyAuthenticated()
      )
      .build();
}

In this example, we use anonymous() to ensure only unauthenticated users can reach /login, authenticated() requires a user to be logged in for /dashboard, and fullyAuthenticated() mandates a fresh login for sensitive /settings access, enhancing security.

4.5. principal, authentication

Spring Security provides access to the current user’s authentication details through the Principal and Authentication objects. These objects contain information about the authenticated user, such as their username and roles.

For instance, when a user makes a request to a protected endpoint, we can retrieve their details using the Principal object:

@GetMapping("/profile")
public String profile(Principal principal) {
    return "Hello, " + principal.getName();
}

In this example, the profile() method extracts the logged-in user’s name from the Principal object and returns a greeting message.

Alternatively, if we need more details about the authentication, such as roles or authentication type, we can use the Authentication object instead:

@GetMapping("/user-details")
public String userDetails(Authentication authentication) {
    return "User: " + authentication.getName() + ", Roles: " + authentication.getAuthorities();
}

4.6. hasPermission() APIs

The hasPermission expression is part of Spring Security’s ACL system, allowing fine-grained permission checks on domain objects. Instead of just checking roles (like hasRole(‘ADMIN’)), it verifies specific permissions for a given resource.

For example, we can enforce that only users with the isEditor permission can approve articles:

@PreAuthorize("hasPermission(#article, 'isEditor')")
public void acceptArticle(Article article) {
   ...
}

To use hasPermission, we must configure a custom PermissionEvaluator. This evaluator defines how permissions are checked for different objects:

@Override
protected MethodSecurityExpressionHandler expressionHandler() {
    DefaultMethodSecurityExpressionHandler expressionHandler = 
      new DefaultMethodSecurityExpressionHandler();
    expressionHandler.setPermissionEvaluator(new CustomInterfaceImplementation());
    return expressionHandler;
}

5. Method-Level Security With @PreAuthorize and @PostAuthorize

Spring Security also allows us to apply security expressions at the method level. With @PreAuthorize and @PostAuthorize, we can execute security checks before or after a method executes. This is particularly useful when securing services based on roles or other conditions.

This example ensures that only users with the ADMIN role can execute the deleteUser() method:

@PreAuthorize("hasRole('ADMIN')")
public void deleteUser(User user) {
    // Method logic
}

In contrast, @PostAuthorize() ensures that the user can only view their own user object after the method has executed:

@PostAuthorize("returnObject.owner == authentication.name")
public User getUser(Long id) {
    // Fetch the user and return
}

6. Path Variables and @PreFilter / @PostFilter

Spring Security also supports filtering collections in methods using @PreFilter and @PostFilter. This is useful when we need to filter data before or after method execution, based on the logged-in user’s authorities or other criteria.

The @PreFilter annotation ensures that only certain elements in a collection are passed to the method, filtering out unauthorized ones before execution:

@PreFilter("filterObject.owner == authentication.name")
public void updatePosts(List<Post> posts) {
    // Update posts for the user
}

The expression filterObject.owner == authentication.name ensures that only posts owned by the logged-in user (authentication.name) are processed.

The @PostFilter annotation ensures that only allowed elements are returned to the caller after execution. This is useful when retrieving data but restricting access to only authorized items. Let’s take a look at this example:

@PostFilter("filterObject.owner == authentication.name")
public List<Post> getPosts() {
    // Get all the posts and ret
}

The @PostFilter annotation filters out any posts that do not belong to the currently authenticated user.

7. Conclusion

In this article, we explored key Spring Security expressions and how they can be applied to protect your web application. By leveraging expressions like hasRole(), hasAuthority(), permitAll(), and various authentication-related expressions, we can fine-tune the security of our application. Additionally, using @PreAuthorize, @PostAuthorize, @PreFilter, and @PostFilter allows for more granular control over method-level security and data filtering.