Securing API Endpoints with RBAC

1. What is Role-Based Access Control (RBAC)?

At its core, RBAC is a security design pattern where access rights are grouped by role.

• A User is an individual interacting with the system (e.g., john.doe).
• A Role is a collection of permissions that represents a job function or level of authority (e.g., ADMIN, EDITOR, VIEWER).
• A Permission is the right to perform a specific action (e.g., CREATE_PRODUCT, DELETE_USER).

In many simpler systems, permissions are implicitly tied to roles. For example, the ADMIN role might implicitly have all permissions. Today, we'll focus on this common model where roles themselves are the core of our authorization logic.

2. Designing the Database for Roles

To implement RBAC, we first need a way to store user and role information in our database. Since a single user can have multiple roles (e.g., someone could be both an EDITOR and a VIEWER), and a single role can be assigned to many users, this is a classic many-to-many relationship.

The standard way to model this in a relational database like MySQL is with three tables:

1. users: Stores user credentials like username and password.
2. roles: Stores the available role names (e.g., 'ADMIN', 'USER').
3. users_roles: A join table that links users to their roles.

3. Mapping the Database Schema to JPA Entities

Now that we have a database structure, we need to represent it in our Java application using JPA entities. You'll need an entity for Role and you'll need to update your existing User entity to map the many-to-many relationship.

Spring Data JPA makes this straightforward with the @ManyToMany annotation. You will add a Set<Role> field to your User class, which will hold all the roles associated with that user.

4. Loading Roles as GrantedAuthority

Spring Security doesn't work with your custom Role entity directly. Instead, it operates on a generic interface called GrantedAuthority. Our next task is to "translate" the roles we load from the database into a collection of GrantedAuthority objects.

We do this inside the UserDetails implementation that you created in a previous lesson. The getAuthorities() method is where this conversion happens. You will iterate over the Set<Role> from your User entity and create a SimpleGrantedAuthority for each one.

This step is the critical bridge connecting your database data to the Spring Security framework.

5. Applying RBAC Rules to Secure Endpoints

With the setup complete, Spring Security is now aware of each user's roles upon authentication. We can finally use this information to secure our API endpoints. There are two primary ways to do this, and they work together beautifully.

Roles vs. Authorities: An Important Distinction

Before we apply the rules, it's crucial to understand a subtlety in Spring Security.

• Role: A role is often prefixed with ROLE_ by convention. The hasRole("ADMIN") expression automatically looks for an authority named ROLE_ADMIN.
• Authority: An authority is a more generic term for a permission. It doesn't have a special prefix. The hasAuthority("ADMIN") expression looks for an authority named ADMIN.

Using authorities is generally more flexible and is the recommended practice. It avoids the magic of the ROLE_ prefix.

Method 1: URL-Based Authorization (Coarse-Grained)

You can define broad access rules for URL patterns in your SecurityFilterChain bean. This is excellent for coarse-grained control, such as restricting all endpoints under /api/admin/** to users with the ADMIN authority.

Method 2: Method-Level Security (Fine-Grained)

For more specific rules, we turn to the @PreAuthorize annotation you learned about in the last lesson. Now, you can use role-based expressions like hasAuthority('ADMIN') directly on your controller or service methods. This approach is perfect when access depends not just on the URL, but on the specific operation being performed.

Best Practice: Combine both methods. Use URL-based security for broad rules and supplement it with method-level security for specific, fine-grained exceptions and logic.

@DeleteMapping("/api/posts/{postId}")
@PreAuthorize("hasAuthority('ADMIN')")
public ResponseEntity<Void> deletePost(@PathVariable Long postId) {
    // ... logic to delete the post
    return ResponseEntity.noContent().build();
}

Conclusion

Congratulations! You have now implemented a complete, database-driven Role-Based Access Control system. This is a foundational skill for building secure, enterprise-grade backend applications.

Key Takeaways:

• RBAC simplifies permission management by using roles as an intermediary between users and permissions.
• A many-to-many database relationship (users, roles, users_roles) is the standard way to model this.
• JPA's @ManyToMany annotation maps this database structure into your application's entities.
• Your UserDetails implementation must convert your Role entities into GrantedAuthority objects for Spring Security to use.
• You can enforce RBAC rules using both coarse-grained URL patterns in SecurityFilterChain and fine-grained @PreAuthorize annotations on methods.

What's Next?

We've now built a robust authentication and authorization system based on database-stored credentials and roles. This is a classic "stateful" approach, where the server typically maintains a session for the logged-in user.

In our next lesson, we will explore a modern, "stateless" alternative: JSON Web Tokens (JWT). We'll learn how JWTs work, why they are so popular in microservices and modern web applications, and how to implement them in Spring Boot.