Interface AuthBackend

public interface AuthBackend
CloudForge Manager's Users-page CRUD, abstracted over whichever directory of accounts is currently authoritative — the local H2/Postgres DB, or an AWS Cognito User Pool. Replaces a single persisted boolean flag (AuthBackendStore.Config#cognitoEnabled()) that used to be branched on individually inside every one of AuthService's five user-management methods (listUsers/createLocalUser/updateUser/revokeSessions/ deleteUser) — AuthService now resolves one AuthBackend implementation per call and delegates through it uniformly.

Deliberately scoped to exactly this — Users-page CRUD — and nothing else. Caller/session resolution during normal request handling (AuthService.resolveCaller/ ensureOidcUser) branches only on authMode() (the *sign-in* mechanism: none/alb-oidc/ application-oidc) and always resolves through the local manager_user table regardless of which AuthBackend is active for account CRUD — a Cognito-backend-enabled account still signs in via whatever OIDC flow authMode configures, gets upserted into the local table on each successful principal, and its Caller/role come from that local row. Expanding this interface to also own caller/session resolution would be an unrelated behavior change no one asked for; if that ever needs to change, it's a deliberate, separate decision, not a consequence of this interface's existence.

Implementations: LocalH2AuthBackend (wraps UserStore+SessionManager) and CognitoAuthBackend (wraps CognitoUserManagementService), both in cloudforge-manager — this interface and its DTOs (AuthAccount, AuthAccountRequest, AuthAccountUpdate) live in cloudforge-core because they're plain contracts with no Spring/persistence dependency, following the same split ApplicationSpec/DatabaseSpec already establish for this module.

  • Method Details

    • listAccounts

      List<AuthAccount> listAccounts()

    • createAccount

      AuthAccount createAccount(AuthAccountRequest request)

    • updateAccount

      AuthAccount updateAccount(String accountId, AuthAccountUpdate update)

    • revokeSessions

      AuthAccount revokeSessions(String accountId)
      Invalidates every active session/token for this account without deleting it — the local equivalent of Cognito's AdminUserGlobalSignOut. Returns the (unchanged) account so callers can render an up-to-date view without a second lookup.

    • deleteAccount

      void deleteAccount(String accountId)

    • prepareForIncomingMigration

      default void prepareForIncomingMigration()
      One-time setup a backend needs before it can accept migrated-in accounts (e.g. Cognito's IAM role groups must exist before a migration starts adding users to them). Called once per migration run, before the first createAccount(AuthAccountRequest). No-op by default — LocalH2AuthBackend has nothing to prepare.

    • findAccount

      default Optional<AuthAccount> findAccount(String accountId)
      Finds one account by its AuthAccount.id(), or empty if this backend has no such account. Exists so callers that only have an id — e.g. Access Control's policy-override editor, given whatever id listAccounts() last handed the frontend — can resolve a username/role for display without requiring the account to also exist somewhere else (the bug this closes: Access Control used to look a Cognito-backend account's id up in Manager's own local user table only, which a pure-Cognito account with no local row — never having signed in through application-oidc — was never going to be in, producing "user not found" for an account listAccounts() had just shown a moment earlier).

      Default implementation scans listAccounts() — correct for any backend, just not the cheapest possible lookup; override when a backend can look up a single account more directly (see CognitoAuthBackend).