Custom permission evaluator in Spring Boot - Performance & Optimization

Performance: Custom permission evaluator

MEDIUM IMPACT

This affects the speed of authorization checks during user interactions, impacting input responsiveness and overall user experience.

Checking user permissions for each secured method call

Spring Boot

public boolean hasPermission(Authentication auth, Object targetDomainObject, Object permission) {
    // Use cached permissions stored in Authentication object
    Set<String> permissions = auth.getAuthorities().stream()
        .map(GrantedAuthority::getAuthority)
        .collect(Collectors.toSet());
    return permissions.contains(permission);
}

Avoids repeated database calls by using cached permissions, reducing latency in permission evaluation.

📈 Performance Gainreduces permission check time to under 1ms, improving input responsiveness

Checking user permissions for each secured method call

Spring Boot

public boolean hasPermission(Authentication auth, Object targetDomainObject, Object permission) {
    // Heavy database call on every permission check
    User user = userRepository.findByUsername(auth.getName());
    return user.getPermissions().contains(permission);
}

This pattern triggers a database query on every permission check, causing delays and blocking user interactions.

📉 Performance Costblocks rendering for 50-100ms per check depending on DB latency

Performance Comparison

Pattern	DB Calls	Permission Checks	Latency Impact	Verdict
Direct DB call per check	Multiple per request	High	50-100ms delay per check	[X] Bad
Cached permissions in Authentication	None after login	Low	Under 1ms per check	[OK] Good

Rendering Pipeline

Custom permission evaluation happens during request processing before rendering. Slow permission checks delay response generation, affecting interaction responsiveness.

→Request Handling

→Authorization Check

→Response Generation

⚠️ BottleneckAuthorization Check stage due to expensive permission lookups

Core Web Vital Affected

INP

This affects the speed of authorization checks during user interactions, impacting input responsiveness and overall user experience.

Optimization Tips

1Avoid database calls inside permission evaluators on every request.

2Cache user permissions in the security context or Authentication object.

3Measure authorization latency to ensure it does not block user interactions.

Performance Quiz - 3 Questions

What is the main performance issue with querying the database on every permission check?

A It improves security by always checking fresh data

B It reduces memory usage

C It causes repeated blocking calls that increase request latency

D It speeds up rendering by preloading data

DevTools: Spring Boot Actuator / Application Logs

How to check: Enable debug logging for security and monitor logs for permission evaluation duration; use Actuator metrics to track request latency.

What to look for: Look for long delays in authorization logs or high request processing times indicating slow permission checks.

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()