Namespace Kuestenlogik.Bowire.Auth

Classes

BowireAuthOptions

Configuration for the Bowire auth seam. Bound from Bowire:Auth by AddBowireAuth.

BowireAuthPolicies

Policy names used by Bowire's endpoint mapping. The single Default policy is wired by ApplyAuthentication(IServiceCollection, IConfiguration, BowireAuthOptions, ILogger?) and consumed by BowireApiEndpoints.Map via .RequireAuthorization(BowireAuthPolicies.Default).

BowireAuthProviderRegistry

Assembly-scan registry for IBowireAuthProvider implementations — mirrors BowireProtocolRegistry. At most one provider is active per process; selection happens via ProviderId.

BowireAuthServiceCollectionExtensions

Wires the Bowire auth seam into the host's IServiceCollection. Pairs with the .RequireAuthorization(BowireAuthPolicies.Default) calls inside BowireApiEndpoints.Map.

BowireUserContext

Static facade the per-user stores call through to resolve paths. Defaults to Instance; the host can swap in a request-aware implementation by setting Current at startup (single-user override) or via an async-local HttpContext-driven middleware (multi-tenant mode, once SCIM lands).

CookieJar

Per-environment in-memory cookie store. Bowire holds one CookieContainer per environment id while the workbench process runs; the REST plugin hands the container to a fresh per-call HttpClientHandler when the JS layer marked the request with MarkerKey, so cookies set by one call (e.g. POST /login) ride along on every following call to the same origin (GET /me).

Memory-only by design: process restart wipes the jar, which mirrors what an actual logged-out browser session looks like. Persistent storage would buy little since secrets in cookies are already short- lived and the user can re-authenticate trivially.

CookieSnapshot

Wire shape for the workbench's cookies-list endpoint.

DefaultBowireUserStore

Default IBowireUserStore implementation -- the legacy single-user layout under ~/.bowire/. Installations that don't opt into multi-tenant mode (issue #28) use this transparently and see no behavioural change.

LocalhostCertTrust

Resolves whether a Bowire protocol plugin should trust a self-signed certificate served from a loopback address. Off by default — production hosts always validate strictly via the OS trust store. The opt-in is designed for the ASP.NET Core dev-certs flow on developer machines and CI containers where dotnet dev-certs https --trust hasn't run.

Settings hierarchy (first hit wins):

  • Bowire:{PluginId}:TrustLocalhostCert — per-plugin override. Use when one plugin needs different cert handling than the host's global default (e.g. enable for SignalR but stay strict for REST).
  • Bowire:TrustLocalhostCert — global default for every TLS- bearing plugin. Recommended choice for a typical local-dev host.
  • Otherwise — false.

Even when the flag is on, the relaxed validation only fires for URLs whose host is localhost, 127.0.0.1 or ::1. A production hostname accidentally seen by a misconfigured Bowire host is still validated against the OS trust store.

MtlsCertOwner

Lightweight cert-only owner for transports that don't go through an HttpMessageHandler — primarily System.Net.WebSockets.ClientWebSocket, which exposes its own ClientCertificates + RemoteCertificateValidationCallback on ClientWebSocketOptions. Disposes the loaded X509 resources when the channel goes away.

MtlsCertificatePair

Disposable wrapper for the client- and (optional) CA-certificate pair produced by TryLoadCertificates(out string?). Callers use a using declaration so the analyzer can see disposal on every exit path; once ownership of the inner X509 resources has been handed off to a long-lived owner (MtlsHandlerOwner, MtlsCertOwner), Release() turns the wrapper's own Dispose into a no-op so the certificates aren't torn down with the pair going out of scope. Cleaner than three out parameters plus a CA2000 suppression at every call site.

MtlsConfig

Decoded mTLS client-cert configuration carried inline in the request metadata dict via MtlsMarkerKey. Shared between the REST plugin (HttpClientHandler) and the gRPC plugin (SocketsHttpHandler) so every TLS-capable transport speaks the same wire format and only one PEM parser exists in the codebase.

MtlsHandlerOwner

Bundles a pre-configured HttpMessageHandler with the X509 resources whose lifetime must match it. Disposing the owner disposes the handler and every cert it holds — caller places this in the finally next to the per-call HttpClient / GrpcChannel.

One owner type rather than one per protocol: REST uses HttpClientHandler (its ClientCertificates collection is the natural shape); gRPC uses SocketsHttpHandler (its SslOptions property carries the same data via SslClientAuthenticationOptions). Both inherit from HttpMessageHandler, so callers can hold the abstract base type without caring which factory built it.

Interfaces

IBowireAuthProvider

Extension point for "who is allowed to use this Bowire workbench" — sibling to IBowireProtocol (wire plugins) and IBowireUiExtension (UI widgets). Concrete providers ship as separate NuGet packages (e.g. Kuestenlogik.Bowire.Auth.Oidc) so heavyweight dependencies (Microsoft.Identity.Web, SAML libs, &c) only land in installs that actually use them.

IBowireUserStore

Resolves on-disk storage paths for per-user Bowire state (environments, recordings, collections, flows, &c.). The default implementation returns the legacy single-user layout under ~/.bowire/; multi-tenant deployments (issue #28) swap in an implementation that scopes paths by the authenticated user's sub claim into ~/.bowire-server/users/<sub>/.