v00.70.00 — Planned

Theme

v00.60.00 stabilised the foundations: authentication, authorization, audit, brute-force protection, SessionPolicy, logout, three adapters plus a standalone adapter, and four demo UIs. v00.70.00 builds on top and sharpens the production-integration points without ripping up the existing adapters: policies, persistence, active sessions, and store-backed services.

The version stays in the project’s house style — small SPIs, clear defaults, good testability, no hard binding to Spring, JPA, or a specific database.

Planned capabilities

1. Policy API + Java Builder DSL

Decisions that go beyond plain role or permission checks get an explicit policy model.

• Policy API as a typesafe Java builder
• PolicyRegistry for registration + evaluation
• PolicyDecision with at least Allowed, Denied, StepUpRequired
• @RequiresPolicy annotation for service-level and adapter-spanning checks
• Good debug + audit explanations per policy decision

Policy.named("document.owner-or-admin")
    .when(Action.is("document:update"))
    .allowIf(SubjectPredicates.hasRole("ADMIN"))
    .orIf(ResourcePredicates.ownerMatchesSubject("document"))
    .deny("Only admins or owners may update documents");

Non-goal: an external text DSL. A typesafe Java builder fits the framework’s style.

2. Resource-Based Authorization

Authorization that can reason about concrete resources, not only abstract permissions. Planned bricks: ResourceRef, ResourceResolver, ResourceAccessContext, PolicyRegistry integration, plus test helpers.

3. Method Security

Security closer to critical business operations:

public interface DocumentService {
  @RequiresPolicy("document.owner-or-admin")
  void updateDocument(DocumentId id, DocumentPatch patch);

  @RequiresPermission("document:read")
  Document load(DocumentId id);
}

Implementation candidates: dynamic proxies for interfaces (reusing the existing Secured.wrap mechanism), optional method-interceptor, existing annotations + new @RequiresPolicy.

4. Store-agnostic Persistence API

The persistence layer becomes an API/SPI above concrete stores. Eclipse Store is the preferred reference implementation, not part of the core concept.

Planned store interfaces:

AuditEventStore
LoginAttemptStore
SessionStore
RoleAssignmentStore
RememberMeTokenStore
BootstrapStateStore

5. Eclipse Store Reference Implementation

First production-grade store implementation. EclipseStoreSecurityRoot holds the audit-event list, login-attempt map, sessions, role assignments, and remember-me tokens — but stays an adapter-internal implementation detail. Not exposed via the public persistence API.

6. Tenant Readiness

A foundation for multi-tenant deployments without forcing a tenant admin model:

public record TenantId(String value) {
  public static final TenantId DEFAULT = new TenantId("default");
}

Tenant-ready records and keys: LoginAttemptKey, RoleAssignmentKey, SessionRecord, RememberMeTokenRecord, BootstrapState, AuditEnvelope. Design rule: every user-, role-, session- or security-state-related store carries TenantId in its key or record. Single-tenant apps transparently use TenantId.DEFAULT.

7. Production-grade Active Sessions

Active sessions react to security-relevant changes:

• Role refresh during active sessions
• SecurityVersion per subject/tenant
• Session invalidation on critical role changes
• Remote logout
• LogoutScope.AllSessionsOfSubject becomes store-backed
• Persistent or cluster-capable SubjectSessionRegistry

public record SessionRecord(
    SessionId sessionId,
    SubjectId subjectId,
    TenantId tenantId,
    Instant createdAt,
    Instant lastActivityAt,
    SecurityVersion securityVersionAtLogin,
    SessionStatus status
) {}

8. Store-backed Services

Existing framework services run optionally store-backed without forcing applications to handle store interfaces everywhere:

StoreBackedSecurityAuditService
StoreBackedLoginAttemptPolicy
StoreBackedSubjectSessionRegistry
StoreBackedRoleAuthorizationService
StoreBackedRememberMeService
StoreBackedBootstrapStateService

9. Contract Test Kit for Stores

Every store implementation has to pass the same contract tests, shipped in security-persistence-testkit. Example:

public interface LoginAttemptStoreContract {
  LoginAttemptStore store();

  @Test
  default void savedStateCanBeLoaded() {
    LoginAttemptKey key = new LoginAttemptKey(
        TenantId.DEFAULT, "alice", "127.0.0.1");
    LoginAttemptState state = ...;

    store().save(key, state);

    assertEquals(Optional.of(state), store().find(key));
  }
}

10. Account Lifecycle — Password Reset & Email Verification

PasswordResetService
PasswordResetTokenStore
EmailVerificationService
EmailVerificationTokenStore

• TTL + single-use tokens
• Never store tokens in cleartext — hash or fingerprint only
• Audit events: PasswordResetRequested, PasswordResetCompleted, EmailVerificationRequested, EmailVerified
• Tenant-ready store keys
• Demos show a simple reset flow without requiring a real mail provider

The mail sender stays a small SPI (SecurityNotificationSender) — the framework is not going to ship a full mail framework.

11. Tokens, API Keys, Rate Limiting

API foundation prepared in 00.70 (full OAuth2/OIDC stays 00.80):

ApiKeyResolver
ApiKeyStore
ApiKeyHasher
TokenService
RefreshTokenStore
RateLimitPolicy
RateLimitStore

• API keys for headless usage with permission scopes
• Short-lived access tokens, rotating refresh tokens
• Refresh tokens stored hashed only
• Rate limiting modelled separately from LoginAttemptPolicy: endpoint, subject, IP, tenant buckets
• Audit events for API-key usage, token rotation, rate-limit denials

12. Authorization Ergonomics

• RoleHierarchy (e.g. ROLE_ADMIN implicitly contains ROLE_USER)
• @RequiresAnyPermission, @RequiresAllPermissions

Both stay compatible with the Policy DSL — shorter forms for common cases, @RequiresPolicy for the complex ones.

13. Session-Management UI + Vaadin Components

SessionManagementView
SecuredButton
SecuredMenuItem
SecuredRouterLink

Admins can see and revoke active sessions. Vaadin components automatically hide / disable when an operation isn’t permitted — integrating with operation discovery, permission checks, and later policies.

14. Developer Experience

security-test
FakeAuthenticationService
InMemoryTokenService
SecurityTestExtension
OpenApiSecurityMetadataGenerator

Apps can write security tests without SPI boilerplate. REST endpoints can document permission/policy metadata in OpenAPI.

Proposed module structure

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

security-persistence-eclipsestore   (new)
security-persistence-testkit        (new)
security-test                       (new)

demo-vaadin
demo-rest
demo-standalone
demo-vaadin-rest-client

Possible later additions: security-persistence-jdbc, security-persistence-redis, security-persistence-eventstream, security-quarkus.

Acceptance criteria

• security-core has no Eclipse-Store dependency
• No public API type called SecurityRoot
• Eclipse-Store root classes live exclusively in the Eclipse-Store module
• Store interfaces are small and domain-shaped
• Store keys and records are tenant-ready; TenantId.DEFAULT enables simple single-tenant use
• Eclipse-Store implementation passes the contract tests
• Existing in-memory implementations stay available for tests + demos
• Role refresh works for active sessions
• One demo runs against Eclipse Store as persistence backend
• Password reset + email verification modelled as SPI/store foundation
• API-key, refresh-token, rate-limiting foundations tenant-ready
• Session-management UI can list and revoke active sessions

Non-goals

• No complete tenant-admin model
• No JDBC / Redis implementation in this version
• No external policy text language
• No OIDC/OAuth2 integration (stays 00.80)
• No WebAuthn/MFA implementation (stays 00.80)
• No mandatory SIEM / event bus
• No Quarkus adapter as a required deliverable
• No security-javafx — security-standalone already covers Swing / JavaFX / CLI functionally

Source

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