v00.80.00 — Planned

Theme

v00.70.00 makes policies, persistence, and active sessions production-ready. v00.80.00 builds on top for systems with higher protection needs: strong authentication, external identities, forensics, operations integration, and clear hardening modes.

The framework stays pluggable. High-security features ship as optional modules and SPIs — never as forced complexity for simple applications.

Planned capabilities

1. MFA + Step-Up Authentication

A small SPI for multi-factor authentication and step-up decisions:

MfaService
StepUpPolicy
StepUpChallenge
StepUpDecision

Integration into the Policy DSL via StepUpRequired. Audit events for MFA success, failure, and step-up demand.

Policy.named("admin.user-delete")
    .when(Action.is("user:delete"))
    .require(SubjectPredicates.hasPermission("admin:users:delete"))
    .requireStepUp("mfa", Duration.ofMinutes(5))
    .deny("User deletion requires recent MFA");

First scope candidate: TOTP + recovery codes. WebAuthn / Passkeys may follow as a separate module.

2. WebAuthn / Passkeys

WebAuthnCredentialStore
WebAuthnChallengeStore
PasskeyRegistrationFlow
PasskeyAuthenticationFlow

Hard requirements:

• Credentials never treated as cleartext secrets
• Challenge lifetime strictly bounded
• Device/credential metadata audited
• Recovery + deactivation flows defined

3. OIDC / OAuth2 Bridge

Bridge — not a replacement — for external identity providers. Translates external claims into internal SecuritySubject, roles, permissions, and tenant context. Internal authorization stays framework-owned.

Possible SPIs:

ExternalIdentityResolver
ClaimsToSubjectMapper
ClaimsToRolesMapper
ClaimsToTenantMapper
IdentityProviderSessionLink

Non-goal: a complete replacement for established OIDC clients, or hard coupling to Keycloak / Entra ID / Auth0 / any specific provider.

4. Device + Remember-Me Management

Builds on the v00.70 store interfaces:

DeviceRegistry
RememberMeService
RememberMeTokenHasher
DeviceRiskEvaluator

• Show + revoke trusted devices
• Rotate remember-me tokens
• Store only hashes or fingerprints
• Tenant-aware + subject-aware device management
• Invalidate suspicious devices
• Force step-up when a new or risky device is used

5. Risk-Based Authentication

Login decisions can incorporate risk signals — new IP, unknown device, unusual hour, suspicious failure pattern, tenant switch, new region, old/risky session.

Decisions:

Allow | Deny | Delay | StepUpRequired | Lockout

Every risk decision must be auditable and explainable.

6. Password Hardening

• Argon2id as an additional PasswordHasher
• Pepper support via a separate secret (PasswordPepperProvider SPI — no core-mandated secret management)
• Hash-policy versioning
• Automatic rehash migration
• Password blocklists
• Audit events for policy violations without secret leakage

7. Tamper-Evident Audit

Audit extended for forensic and compliance scenarios:

AuditChainStore
AuditIntegrityVerifier
SignedAuditBatch
AuditExportService

• Hash-chaining of audit events
• Signed audit batches
• Append-only store model
• Verifiable exports
• Integrity checks

Extends — does not replace — the persistent audit from v00.70.

8. Security Event Bus

Live reactions next to historical audit. Audit stays the record of truth; the event bus enables operative response.

Event categories:

Login | Logout | AccessDenied | Lockout | MFA | Token
Session | RoleChanged | DeviceChanged | PolicyDenied

Possible adapters:

LoggingEventPublisher
WebhookEventPublisher
OpenTelemetryEventPublisher
EventStreamPublisher

9. Operations + Monitoring

Runtime metrics + health signals so production systems aren’t only tested but also operated and observed.

Metrics: login successes/failures, lockout counters, denied decisions, MFA outcomes, active sessions, revoked sessions, audit-store lag, event-bus errors.

SPIs:

SecurityMetricsPublisher
SecurityHealthIndicator
SecurityDiagnostics

No monolithic monitoring stack — just clean export points.

10. Fail-Closed Strict Mode

Safe defaults under misconfiguration:

• Missing SPI → Deny, not Allow
• Unknown permission → Deny
• Unknown policy → Deny
• Evaluator error → Deny
• Audit failure → block or alarm, configurable
• Unclassified route → may be blocked

Strict mode needs excellent error messages so operators can quickly see what configuration is missing.

11. Supply-Chain + Release Hardening

For a security framework, the supply chain is part of the product:

• SBOM as a release artefact
• Dependency allowlist
• CVE gates
• Signed artefacts
• Reproducible-build verification
• Provenance / SLSA preparation
• Release checklist for security-relevant changes

12. CSRF + Web-Adapter Hardening

OriginHeaderCheck
DoubleSubmitCookie
CsrfTokenStore
CsrfProtectionPolicy

• CSRF protection as optional SPI for REST + Vaadin-near flows
• Safe defaults for state-changing requests
• Clear opt-outs for pure bearer-token APIs
• Audit / monitoring signals on CSRF denial

13. Privacy, Retention, Backup + Restore

GDPR-driven needs:

UserAnonymizationService
RetentionPolicy
SoftDeletePolicy
SecurityBackupService
SecurityRestoreService

• PII can be anonymised while audit proof survives
• Users and security records support soft-delete
• Retention policies define lifetime + deletion behaviour
• Backup/restore is admin-protected and auditable

14. Additional Integration Modules (optional)

Not every idea needs to be in v00.80’s core scope:

security-quarkus
security-persistence-jdbc
security-persistence-redis
security-persistence-eventstream

The Quarkus adapter only enters once Policy API, Persistence API, and Identity Bridge are stable enough that it’s not built against moving targets.

Proposed module structure

security-core
security-vaadin
security-rest
security-standalone

security-persistence-eclipsestore

security-mfa-api                 (new)
security-mfa-totp                (new)
security-webauthn                (new)
security-identity-oidc           (new)
security-monitoring              (new)
security-audit-integrity         (new)
security-privacy                 (new)
security-web-hardening           (new)

Module boundaries stay pragmatic. APIs containing only interfaces and records may stay in the core, as long as they don’t pull optional external dependencies.

Acceptance criteria

• MFA/step-up integrates via policy decisions
• OIDC/OAuth2 bridge translates external identity into internal subjects
• Remember-me + device management use no cleartext tokens
• Risk-based authentication is auditable
• Argon2id is available as PasswordHasher
• Tamper-evident audit can verify event chains
• Security Event Bus serves at least logging + webhook
• Monitoring export points deliver usable operations data
• Strict mode is documented and testable
• Supply-chain checks are part of the release documentation
• CSRF protection exists as policy/filter foundation for relevant adapters
• Privacy / retention concepts expressible via SPIs

Non-goals

• No complete IAM system
• No user management for all IdPs
• No SIEM as a framework component
• No mandatory WebAuthn for all applications
• No automatic migration of arbitrary legacy identities
• No hard cloud-provider binding
• No Quarkus adapter as a core deliverable while Policy / Persistence / Identity APIs are not yet stable
• No security-javafx while security-standalone covers the needed desktop flows

Source

Konzept-V00.80.00.md in the project repository is the canonical design document.