Custom permission evaluator in Spring Boot - Step-by-Step Execution

Concept Flow - Custom permission evaluator

User requests access

↓

Security checks permission

↓

Call CustomPermissionEvaluator

↓

Evaluate permission logic

↓

Return true: Access granted

↓

Return false: Access denied

When a user requests access, Spring Security calls the custom permission evaluator to check if the user has the required permission and returns true or false.

Execution Sample

Spring Boot

public class CustomPermissionEvaluator implements PermissionEvaluator {
  @Override
  public boolean hasPermission(Authentication auth, Object target, Object perm) {
    // custom logic
    return true; // or false
  }

  @Override
  public boolean hasPermission(Authentication auth, Serializable targetId, String targetType, Object perm) {
    // custom logic for this method if needed
    return false;
  }
}

This code defines a custom permission evaluator that Spring Security uses to decide if a user has permission.

Execution Table

Step	Input Parameters	Permission Check Logic	Result	Access Outcome
1	auth=UserA, target=Document1, perm='read'	Check if UserA has 'read' on Document1	true	Access granted
2	auth=UserB, target=Document1, perm='write'	Check if UserB has 'write' on Document1	false	Access denied
3	auth=UserA, target=Document2, perm='delete'	Check if UserA has 'delete' on Document2	false	Access denied
4	auth=Admin, target=Any, perm='all'	Admin has all permissions	true	Access granted

💡 Permission evaluator returns true or false to grant or deny access

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4
auth	null	UserA	UserB	UserA	Admin
target	null	Document1	Document1	Document2	Any
perm	null	'read'	'write'	'delete'	'all'
result	null	true	false	false	true

Key Moments - 3 Insights

Why does the permission evaluator return false even if the user is authenticated?

Authentication means the user is logged in, but permission evaluator checks if the user has rights to the specific action on the target. See execution_table rows 2 and 3 where users are authenticated but lack permission.

What happens if the permission evaluator returns true?

Access is granted to the user for the requested action. This is shown in execution_table rows 1 and 4 where result is true and access is granted.

Can the permission evaluator check complex rules?

Yes, it can use any logic inside hasPermission method to decide. The flow in concept_flow shows the evaluator can return true or false based on custom logic.

Visual Quiz - 3 Questions

Look at the execution_table, what is the result of permission check for UserB trying to 'write' Document1?

A false

B true

C null

D throws error

💡 Hint

Check execution_table row 2 under 'Result' column

At which step does the permission evaluator grant access for an admin user?

A Step 1

B Step 4

C Step 3

D Step 2

💡 Hint

Look at execution_table row 4 for 'auth' and 'Access Outcome'

If the permission evaluator always returns true, what changes in variable_tracker 'result' row?

A Values alternate true and false

B All values become false

C All values become true

D Values remain null

💡 Hint

Consider the 'result' values in variable_tracker and what always returning true means

Concept Snapshot

Custom Permission Evaluator in Spring Security:
- Implement PermissionEvaluator interface
- Override hasPermission method
- Use Authentication, target, and permission parameters
- Return true to grant access, false to deny
- Enables custom access rules beyond roles

Full Transcript

In Spring Security, a custom permission evaluator checks if a user has permission to perform an action on a target object. When a user requests access, the security system calls the custom evaluator's hasPermission method with the user's authentication, the target object, and the requested permission. The evaluator runs custom logic and returns true or false. True means access granted, false means denied. The execution table shows examples with different users and permissions. Variables like auth, target, perm, and result change as the evaluator runs. Key moments clarify that authentication alone doesn't guarantee permission, and the evaluator can implement complex rules. The visual quiz tests understanding of permission results and outcomes. This approach lets developers control access precisely in their Spring Boot apps.

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