Skip to content

Guided tour

FabrCore 2.0 · Release and package availability

These guides track the current 2.0 source. Stable 2.0.0 publication is pending; package commands show the release target. Until it is published, follow the source quick start or use a matching available prerelease set. Release migration · Runtime modes

MODULE 08 · LESSON 8.3

Authenticate callers and establish principal ownership

Authenticate at ingress before assigning a FabrCore principal.

Lesson 45 of 86 · FabrCore 2.0

Overview

Identity determines which partition and agents a caller can access. SQL ACL adds authorization; it does not authenticate arbitrary forwarded principal headers. A reverse proxy is part of the trust boundary, not a substitute for it.

Authentication must happen before handle selection

The Host needs a trusted mapping from the authenticated caller to a FabrCore principal. In a proxied application, strip or overwrite untrusted forwarded identity headers at the trusted boundary. Letting a browser choose x-user-handle would let it choose an ownership partition; SQL authorization does not magically authenticate that header.

Use stable identities across sessions

An immutable tenant/user identifier is a better mapping input than a display name or email that can change. The exact mapping is an application decision, but it must be deterministic and isolated across users. Keep client/session state bound to that identity on sign-in, sign-out and account switching.

Bind authentication to principal ownership

  1. Configure ASP.NET Core authentication for the application and validate issuer/audience/callbacks. Map a stable authenticated identifier to the FabrCore principal.
  2. Allow forwarded identity headers only from trusted infrastructure that removes caller-supplied copies. Use the WebSocket ticket's authenticated identity for v2 sessions.
  3. Keep administrative policy/credentials separate from ordinary user chat and scope application services to the current principal.

Try the same handle as two users

  1. Authenticate two test users and create an assistant for each. Inspect the resulting qualified handles and confirm their principal portions differ.
  2. From user A, attempt to select user B by modifying a caller-controlled header. The trusted ingress should overwrite/reject it rather than grant B's identity.
  3. Sign out and sign in as the other user in the client. Verify its workspace, socket checkpoint and conversation selection move to the new account instead of retaining the previous account's state.

This checks identity establishment and client isolation. ACL grants can then authorize specific cross-principal operations without weakening that authentication boundary.

If the result is different

If the Host trusts an unvalidated caller header, enabling SQL does not repair authentication. Trace where the principal was assigned.

Go deeper

Explore the related documentation.