Custom permission evaluator in Spring Boot

Introduction

A custom permission evaluator lets you control who can do what in your app by checking permissions in your own way.

You want to check user permissions beyond simple roles.

You need to decide access based on complex rules or data.

You want to reuse permission logic across many parts of your app.

You want to keep your security checks clean and organized.

Syntax

Spring Boot

public class MyPermissionEvaluator implements PermissionEvaluator {
    @Override
    public boolean hasPermission(Authentication auth, Object targetDomainObject, Object permission) {
        // Your custom logic here
        return false;
    }

    @Override
    public boolean hasPermission(Authentication auth, Serializable targetId, String targetType, Object permission) {
        // Your custom logic here
        return false;
    }
}

Implement the PermissionEvaluator interface to create your own permission checks.

Override both hasPermission methods to handle different permission scenarios.

Examples

This example allows permission only if the user has the 'ADMIN' role.

Spring Boot

public class MyPermissionEvaluator implements PermissionEvaluator {
    @Override
    public boolean hasPermission(Authentication auth, Object targetDomainObject, Object permission) {
        if (auth == null || targetDomainObject == null || !(permission instanceof String)) {
            return false;
        }
        String perm = (String) permission;
        // Example: allow if user has 'ADMIN' role
        return auth.getAuthorities().stream()
            .anyMatch(a -> a.getAuthority().equals("ROLE_ADMIN"));
    }

    @Override
    public boolean hasPermission(Authentication auth, Serializable targetId, String targetType, Object permission) {
        return false;
    }
}

This example checks if the user owns the document before allowing permission.

Spring Boot

public class MyPermissionEvaluator implements PermissionEvaluator {
    @Override
    public boolean hasPermission(Authentication auth, Object targetDomainObject, Object permission) {
        if (targetDomainObject instanceof Document) {
            Document doc = (Document) targetDomainObject;
            String perm = (String) permission;
            // Allow if user owns the document
            return doc.getOwner().equals(auth.getName());
        }
        return false;
    }

    @Override
    public boolean hasPermission(Authentication auth, Serializable targetId, String targetType, Object permission) {
        return false;
    }
}

Sample Program

This custom permission evaluator allows users with the 'ROLE_USER' role to have 'read' permission on any object.

Spring Boot

package com.example.security;

import org.springframework.security.access.PermissionEvaluator;
import org.springframework.security.core.Authentication;
import java.io.Serializable;

public class CustomPermissionEvaluator implements PermissionEvaluator {

    @Override
    public boolean hasPermission(Authentication auth, Object targetDomainObject, Object permission) {
        if (auth == null || targetDomainObject == null || !(permission instanceof String)) {
            return false;
        }
        String perm = (String) permission;

        // Simple example: allow if user has 'ROLE_USER' and permission is 'read'
        boolean hasRoleUser = auth.getAuthorities().stream()
            .anyMatch(a -> a.getAuthority().equals("ROLE_USER"));

        if (hasRoleUser && "read".equalsIgnoreCase(perm)) {
            return true;
        }
        return false;
    }

    @Override
    public boolean hasPermission(Authentication auth, Serializable targetId, String targetType, Object permission) {
        // Not implemented for this example
        return false;
    }
}

Important Notes

Register your custom PermissionEvaluator as a bean in your Spring Security configuration.

Use @PreAuthorize or @PostAuthorize annotations with expressions like hasPermission() to apply your evaluator.

Test your permission logic carefully to avoid accidental access.

Summary

Custom permission evaluators let you write your own rules for who can do what.

Implement the PermissionEvaluator interface and override its methods.

Use your evaluator in security annotations to protect your app.

Practice

1. What is the main purpose of a Custom PermissionEvaluator in Spring Boot security?

easy

A. To handle database connections securely

B. To replace the entire Spring Security framework

C. To define custom rules for checking user permissions in a reusable way

D. To manage user sessions automatically

Solution

1. Step 1: Understand the role of PermissionEvaluator

   The PermissionEvaluator interface allows defining custom logic to check if a user has permission to perform an action.

2. Step 2: Identify the purpose of custom implementation

   Implementing a custom PermissionEvaluator lets you write your own rules that can be reused across your application for security checks.

3. Final Answer:

   To define custom rules for checking user permissions in a reusable way -> Option C

4. Quick Check:

   Custom PermissionEvaluator = Custom reusable permission rules [OK]

Hint: Custom PermissionEvaluator defines reusable permission rules [OK]

Common Mistakes:

• Thinking it replaces Spring Security entirely
• Confusing it with session management
• Assuming it manages database connections

2. Which method must you override when implementing a PermissionEvaluator to check permissions based on a target domain object?

easy

A. checkPermission(Authentication authentication, String permission)

B. hasPermission(Authentication authentication, Object targetDomainObject, Object permission)

C. evaluatePermission(User user, String permission)

D. validatePermission(Object targetDomainObject)

Solution

1. Step 1: Recall PermissionEvaluator interface methods

   PermissionEvaluator has two methods: one with targetDomainObject and one with targetId and targetType.

2. Step 2: Identify the method for domain object permission check

   The method hasPermission(Authentication authentication, Object targetDomainObject, Object permission) is used to check permissions on a domain object.

3. Final Answer:

   hasPermission(Authentication authentication, Object targetDomainObject, Object permission) -> Option B

4. Quick Check:

   Domain object permission method = hasPermission with targetDomainObject [OK]

Hint: Override hasPermission with targetDomainObject for object checks [OK]

Common Mistakes:

• Choosing methods not in PermissionEvaluator interface
• Confusing method parameters
• Using method names that don't exist

3. Given this custom PermissionEvaluator method snippet:

public boolean hasPermission(Authentication auth, Object target, Object perm) {
  if (auth == null || target == null || !(perm instanceof String)) {
    return false;
  }
  String permission = (String) perm;
  User user = (User) auth.getPrincipal();
  return user.getRoles().contains(permission);
}

What will be the result if auth is null?

medium

A. Returns false immediately

B. Throws NullPointerException

C. Returns true by default

D. Ignores null and continues

Solution

1. Step 1: Analyze the null check at method start

   The method checks if auth is null and returns false immediately if so.

2. Step 2: Understand the flow when auth is null

   Since auth == null triggers return false, no further code runs and no exception occurs.

3. Final Answer:

   Returns false immediately -> Option A

4. Quick Check:

   Null auth returns false immediately [OK]

Hint: Null checks return false early to avoid exceptions [OK]

Common Mistakes:

• Assuming NullPointerException will be thrown
• Thinking it returns true by default
• Ignoring the null check logic

4. You wrote this custom PermissionEvaluator method:

public boolean hasPermission(Authentication auth, Object target, Object perm) {
  String permission = (String) perm;
  User user = (User) auth.getPrincipal();
  return user.getRoles().contains(permission);
}

What is the main problem with this code?

medium

A. It should return true by default

B. Casting perm to String is unnecessary

C. User roles cannot be checked this way

D. It lacks null checks and may throw NullPointerException

Solution

1. Step 1: Check for missing null validations

   The method does not check if auth, perm, or auth.getPrincipal() are null before casting or calling methods.

2. Step 2: Understand consequences of missing null checks

   If any are null, the code will throw NullPointerException at runtime.

3. Final Answer:

   It lacks null checks and may throw NullPointerException -> Option D

4. Quick Check:

   Missing null checks cause runtime exceptions [OK]

Hint: Always add null checks before casting or method calls [OK]

Common Mistakes:

• Ignoring null safety
• Thinking casting is always safe
• Assuming roles check is invalid

5. You want to create a custom PermissionEvaluator that allows a user to edit a document only if they have the "EDITOR" role and the document status is "DRAFT".
Which code snippet correctly implements this logic inside hasPermission?

hard

A. if (auth == null || target == null) return false;
User user = (User) auth.getPrincipal();
Document doc = (Document) target;
return user.getRoles().contains("EDITOR") && "DRAFT".equals(doc.getStatus());

B. User user = (User) auth.getPrincipal();
Document doc = (Document) target;
return user.getRoles().contains("EDITOR") || doc.getStatus().equals("DRAFT");

C. if (auth == null) return true;
Document doc = (Document) target;
return doc.getStatus() == "DRAFT";

D. User user = (User) auth.getPrincipal();
return user.getRoles().contains("EDITOR");

Solution

1. Step 1: Check for null authentication and target

   Security checks should return false if authentication or target is null to avoid errors.

2. Step 2: Verify user role and document status conditions

   The user must have "EDITOR" role and the document status must be exactly "DRAFT" for permission to be granted.

3. Step 3: Confirm correct logical operator usage

   Both conditions must be true, so use logical AND (&&), not OR (||).

4. Final Answer:

   if (auth == null || target == null) return false; User user = (User) auth.getPrincipal(); Document doc = (Document) target; return user.getRoles().contains("EDITOR") && "DRAFT".equals(doc.getStatus()); -> Option A

5. Quick Check:

   Check nulls + role AND status = correct logic [OK]

Hint: Use && to combine role and status checks with null safety [OK]

Common Mistakes:

• Using || instead of && for both conditions
• Not checking for null auth or target
• Comparing strings with == instead of equals()