Interface IBowireAuthProvider

Namespace

Kuestenlogik.Bowire.Auth

Assembly

Kuestenlogik.Bowire.dll

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.

public interface IBowireAuthProvider

Remarks

Discovery follows the same assembly-scan pattern as BowireProtocolRegistry: providers are picked up at startup if their assembly is loaded (PackageReference for embedded hosts, ~/.bowire/plugins/ for standalone). At most one provider is active per process — selected by the --auth-provider <id> CLI flag, the Bowire:AuthProvider appsettings key, or the ProviderId property when calling AddBowireAuth() directly.

When no provider is selected (the default), Bowire's endpoints stay open — same behaviour as today's laptop-friendly default. When a provider is selected, ApplyAuthentication(IServiceCollection, IConfiguration, BowireAuthOptions, ILogger?) wires up the auth scheme + an AuthorizationPolicy that every Bowire endpoint enforces via .RequireAuthorization(BowireAuthPolicies.Default).

Embedded mode is unchanged: when the host has its own auth pipeline configured, the host's policy wins. Bowire only attaches its own scheme when the host *opts in* via --auth-provider or the appsettings equivalent.

Properties

Id

Stable id used to select this provider on the CLI / in config (e.g. "oidc", "saml", "apikey"). Compared case-insensitively against --auth-provider <id>.

string Id { get; }

Property Value

string

Name

Human-readable provider name shown in the workbench's "signed in via" surface and in startup logs. Examples: "OpenID Connect", "SAML 2.0".

string Name { get; }

Property Value

string

Methods

AddAuthentication(IServiceCollection, IConfiguration)

Register the authentication scheme + any provider-specific services. Called once at startup, before builder.Build(). Implementations should read their configuration off configuration under Bowire:Auth:<Id> (e.g. Bowire:Auth:Oidc:Authority).

void AddAuthentication(IServiceCollection services, IConfiguration configuration)

Parameters

services IServiceCollection

The host service collection.

configuration IConfiguration

Configuration root — providers should look at Bowire:Auth:<Id> for their own keys.

BuildDefaultPolicy(AuthorizationPolicyBuilder)

Configure the policy that BowireApiEndpoints enforces on every Bowire route. The default implementation requires authenticated user; providers can tighten it (e.g. require a specific claim, role, or audience).

void BuildDefaultPolicy(AuthorizationPolicyBuilder policy)

Parameters

policy AuthorizationPolicyBuilder

Builder pre-seeded with RequireAuthenticatedUser(). Override or extend in concrete providers.

Configure(IApplicationBuilder)

Optional hook for providers that need to insert middleware into the host pipeline — e.g. an OIDC callback path that lives on a stable URL outside the Bowire endpoint group, a claims- transformation step, or a redirect-on-401 handler. Called from BowireApiEndpoints.Map after the standard UseAuthentication / UseAuthorization calls but before the Bowire endpoint group is materialised, so anything the provider mounts here runs before Bowire's own routes.

void Configure(IApplicationBuilder app)

Parameters

app IApplicationBuilder

Remarks

Default implementation is a no-op — most providers configure everything they need through AddAuthentication(IServiceCollection, IConfiguration) because ASP.NET's authentication middleware handles the challenge / sign-in / sign-out handshake without any extra host wiring. Only override when the provider's scheme can't be expressed as pure DI registration.

Privilege boundary. Auth providers loaded as sibling plugins (under ~/.bowire/plugins/) still load through the standard BowirePluginLoadContext; they share the host's copy of every Microsoft.* assembly, so the IApplicationBuilder they receive here is the real host pipeline -- not a sandbox. Treat this hook like any other middleware-registration point: anything mounted here runs with full host trust. Embedded hosts that want a tighter boundary can wrap the auth plugin in a separate load context before passing it to AddBowireAuth.