Monolith -- Fintech RBAC

archivedJava71 · JUnit 5 tests

Role-based access control system with a neobank theme, in Java 21. Four roles and five access scopes, with every decision routed through a single AccessPolicy engine. Uses capability tokens, sealed types, a monadic AccessResult<T> and file-backed JSON persistence.

GitHub ↗

STATUSarchived

LANGUAGEJava

METRIC71 · JUnit 5 tests

STACKJava 21 · RBAC · Sealed Types · Generics · JUnit 5 · JavaFX

REPOmiki-przygoda/Monolith ↗

ACCESS-CONTROL CORE

AccessPolicy is the only policy engine. Account, Resource and ResourceRegistry access all delegate to it, so a rule changed there changes everywhere.
Capability<T extends Action> tokens with Read and Write subtypes, where Write extends Read. The package-private create() stops other packages from forging tokens.
Account and Resource can only be built through their factories using a CreationToken. Direct construction without a factory token throws SecurityException.
AccessResult<T> is a sealed interface over Allowed and Denied records, with PECS-bounded map and flatMap. addBalance chains the read and write checks in one expression.

TESTING

71 JUnit 5 tests. SecurityPenetrationTest has 12 nested groups, covering privilege escalation, capability forgery, factory-token bypass, the scope-role access matrix and immutability invariants.
Uses reflection to check that Capability.create() is not public, that CreationToken and user-type constructors are private, and that the account balance field is private.
Concurrent factory tests check that account IDs stay unique under parallel creation.