Projects / Monolith — Secure Neobank

Monolith — Secure Neobank

archivedJava57+ · security tests

Capability-based access control banking simulator in Java — sealed class hierarchy, package-private capability forgery prevention, PECS-correct AccessResult<T> monad, and a 12-section security penetration test suite validating the full scope-role matrix via reflection.

STATUSarchived
LANGUAGEJava
METRIC57+ · security tests
STACKJava · JavaFX · Sealed Classes · Generics · PECS · Type Safety · JUnit 5
COMMITS2
STARS0
2 commits‹› Code ↗
M
miki-przygodaInitial commit - project src06b4e742 weeks ago
·.gitattributes
·.gitignore
·README.md
·pom.xml
src
📄
Monolith

A fintech-themed role-based access control (RBAC) system built in Java 21 with a JavaFX GUI. The project explores capability-based security, sealed type hierarchies, generic result types, and file-backed persistence — all centred around a multi-role banking domain.

Overview

Monolith simulates a neobank platform where four distinct roles (Customer, Support Staff, Manager, Admin) interact with two resource types (Accounts and Documents) across five access scopes (Public, Internal, Confidential, Private, System). Every access decision flows through a single policy engine. No role can bypass the access gate — it is structural, not optional.

The name _Monolith_ is a play on monolithic architecture — a deliberate design choice to keep all security logic in one place before it scales.

Features
  • Role-based access control — four roles, five scopes, one central AccessPolicy engine
  • Capability tokens — Capability<T extends Action> with Read and Write subtypes; Write extends Read enforces subtype relationships at compile time
  • Creation token pattern — Account and Resource can only be instantiated via their factories; the CreationToken constructor argument is unforgeable from outside the package
  • Sealed type hierarchy — AuthenticatedUser, AccessResult<T>, and Capability.Action are all sealed, giving exhaustive switch/instanceof coverage
  • Monadic AccessResult<T> — a sealed generic interface (Allowed<T> / Denied<T>) with PECS-correct map and flatMap; denial propagates without null checks or sentinel values
  • File-backed persistence — every user and resource is serialised to JSON under data/; the app fully restores state on startup via ResourceLoaderService
  • SHA-256 authentication — credentials are stored as hashed values in per-user credentials.json files; no global credential store
  • Structured logging — two log files (access.log and system_state.log) via Logback; every access attempt is logged with user ID, role, resource, action, and result
  • JavaFX GUI — MVC layout with a landing page, login, registration, role-scoped dashboard, and resource detail view
  • JMH benchmarks — throughput and allocation benchmarks under benchmarks/
  • 71 JUnit 5 tests — including security penetration tests, concurrent factory tests, and a scope-role access matrix
Architecture
src/main/java/uk/ac/gre/monolith/
├── core/
│   ├── models/          # User, Account, Resource, Role, AccessScope, SecureResource
│   ├── factories/       # UserFactory, AccountFactory, ResourceFactory (token-gated)
│   ├── AccessPolicy     # Sole policy engine — all access decisions delegate here
│   ├── AccessResult     # Sealed generic result type (Allowed / Denied) with map/flatMap
│   ├── Capability       # Generic token type (Read / Write sealed hierarchy)
│   ├── ResourceRegistry # Type-safe runtime resource store
│   └── SystemWideLogger # Structured Logback wrapper
├── services/
│   ├── AuthService      # SHA-256 login, registration, startup user index
│   ├── PersistenceService  # Async queue, JSON serialisation to data/
│   ├── ResourceLoaderService  # Startup resource hydration from data/
│   ├── SeedService      # Idempotent demo data seeder
│   └── ServiceManager   # Singleton lifecycle manager
├── controllers/         # MVC controllers (Landing, Login, Register, Dashboard, ResourceDetail)
├── views/               # JavaFX scenes (matching controllers above)
├── benchmarks/          # JMH throughput and allocation benchmarks
├── Launcher             # JavaFX entry point
└── Main                 # Application bootstrapper
Access Control Rules
| Role          | PUBLIC | INTERNAL | CONFIDENTIAL | PRIVATE       | SYSTEM |
|---------------|--------|----------|--------------|---------------|--------|
| Customer      | R      | —        | —            | R/W (own)     | —      |
| Support Staff | R      | R        | —            | R/W (own)     | —      |
| Manager       | R      | R        | R            | R/W (own)     | —      |
| Admin         | R/W    | R/W      | R/W          | R/W           | R/W    |

Write access for non-admin roles is always restricted to owned resources. Accounts are hardcoded to PRIVATE scope.

Getting Started
Prerequisites
  • Java 21+
  • Maven 3.8+
Build
mvn compile
Run
mvn javafx:run
Format
mvn spotless:apply
ABOUT

Role-based access control system with a fintech theme - Java 21, JavaFX, capability tokens, sealed types.

bankingfintechjava-21monolithrbac
ACTIVITY
Stars0
Forks0
Commits2
License
LANGUAGES
Java95.7%
CSS4.3%
SECURITY MODEL
  • Capability<T> with package-private create() — external packages cannot forge capability tokens; Write extends Read for compile-time subtype enforcement.
  • CreationToken pattern — Account and Resource constructors gated behind factory-only tokens; direct instantiation throws SecurityException.
  • AccessPolicy as sole gatekeeping point — single runtime check covers the entire codebase; all access logged via SystemWideLogger.
  • 5-scope model: PUBLIC, INTERNAL, CONFIDENTIAL, PRIVATE, SYSTEM — role-specific read/write matrix enforced at compile and runtime.
ACCESSRESULT<T>
  • Sealed interface with Allowed<T> and Denied<T> records — replaces ad-hoc sentinel values (-1, 'Null', boolean).
  • map() and flatMap() with PECS-correct bounded wildcards (Function<? super T, ? extends U>) — functional composition for chained access checks.
  • addBalance() implemented as flatMap + map chain — read and write capability checks in a single expression.
TEST SUITE
  • SecurityPenetrationTest — 12 nested classes: horizontal privilege escalation, vertical privilege escalation, capability forgery, factory token bypass, resource ID validation, registry access control, balance manipulation, sealed interface integrity, AccessResult generics semantics, scope-role access matrix, creation scope boundaries, immutability invariants.
  • Capability.create() visibility verified via reflection — confirms package-private enforcement.
  • Concurrent stress test — 200 simultaneous users creating and accessing resources.