-
🕒 Estimated Time: 6–7 hours total
Subtask Estimates
Task Estimated Time Add Spring Security dependencies and config base ~30 mins Configure basic auth or form login ~1 hour Secure endpoints with annotations + test access rules ~1.5 hours Integrate DB-based user + role authentication ~1.5 hours Password encoding and secure admin setup ~1 hour Optional: stub for JWT future use ~30 mins Tests and validation (login + access control) ~1 hour -
SZ-4: Implementation Approach: Spring Security – Hybrid AuthN/AuthZ Strategy
Decision Summary:
We’re going to implement a hybrid auth setup in Sztab. The idea is to use form-based login for the server-rendered web UI, and JWT-based stateless auth for REST APIs and future gRPC endpoints.
This gives us flexibility and a clean separation: web UI users get a traditional login flow with sessions, while API and service clients use tokens.
Comparison:
Form login uses HttpSession and cookies. It works well for server-rendered UIs (like Thymeleaf or JSP), has built-in CSRF/XSRF protection, and is simple to set up. But it requires session tracking on the server and doesn’t scale as easily across instances unless we add sticky sessions or shared session stores.
JWT auth is stateless. Clients send the token in the Authorization header (Bearer token). It works great for REST APIs, mobile apps, SPAs, and gRPC. It scales better, but requires us to handle token generation, validation, expiration, and possibly logout/blacklist mechanics. Also needs us to manage CSRF/XSS carefully if tokens are stored in browser-accessible storage.
Implementation Plan:
We’ll define two separate security filter chains. 1. For /ui/: uses form login, session tracking, and Spring Security defaults. Good for admin pages and server-rendered HTML. 2. For /api/: uses JWT. We’ll create a custom login endpoint (POST /api/auth/login) that returns a JWT. All other API routes will require a valid token. The system will be stateless — no sessions or CSRF protection here.
For gRPC: we’ll reuse the same JWT token and pass it in metadata. Server-side interceptors will validate it using the same logic as the REST filter.
Planned Code Structure: • SecurityConfig.java – defines both chains • JwtTokenProvider.java – creates and validates tokens • JwtAuthenticationFilter.java – filters incoming API requests • UserDetailsServiceImpl.java – loads user info from the DB • AuthController.java – exposes the /api/auth/login endpoint • AuthRequest.java and AuthResponse.java – DTOs for login • application.yml – stores secret key, token expiry config
Summary:
We get sessions for server-rendered pages and stateless JWT for APIs. Clean, scalable, and extensible for future use cases (like service-to-service auth with gRPC).
-
| Type |
New Feature
|
| Priority |
Normal
|
| Assignee | |
| Version |
none
|
| Sprints |
n/a
|
| Customer |
n/a
|
Implement AuthN/AuthZ with Spring Security
Goal:
Introduce basic authentication and authorization mechanisms for securing the Sztab backend. Protect endpoints based on user roles stored in the database.
Estimated Time: 6–7 hours
Task Breakdown
1. Add Spring Security Dependencies
spring-boot-starter-securitytopom.xml2. Configure Basic Auth or Form-Based Login (MVP)
/api/**while allowing unrestricted access to/actuator,/health, etc.3. Secure Endpoints Using Role-Based Access
@PreAuthorizeor@SecuredSecurityFilterChainfor fine-grained config4. Connect Authentication to Database
UserandRolefrom PostgreSQLUserDetailsServiceor use Spring Data integrationGrantedAuthorityobjects5. Password Handling
BCryptPasswordEncoderfor hashing and comparison6. Optional: JWT Stub (For Future)
7. Tests and Validation
Output Artifacts