# AuthN Resolver

Main module for authentication in CyberFabric. Discovers AuthN plugins via GTS types-registry and routes token validation to the selected plugin.

## Overview

The `cf-authn-resolver` module provides:

- **Plugin discovery** — Finds AuthN plugins via GTS types-registry
- **Vendor-based selection** — Selects plugin by vendor and priority
- **Token validation routing** — Delegates bearer token authentication to the active plugin
- **ClientHub integration** — Registers `AuthNResolverClient` for inter-module use

This is a **main module** — it contains no authentication logic itself. All operations are delegated to the active plugin (e.g., `cf-static-authn-plugin` for development, or a custom OIDC/JWT implementation).

## Architecture

```
API Gateway (middleware)
    │
    ▼
AuthNResolverClient  (SDK trait, registered in ClientHub)
    │
    ▼
authn-resolver gateway  (this crate — discovers & routes)
    │
    ▼
AuthNResolverPluginClient  (SDK trait, scoped by GTS instance ID)
    │
    ▼
Plugin implementation  (validates tokens, returns SecurityContext)
```

## Usage

The primary consumer is the API Gateway's authentication middleware:

```rust
use authn_resolver_sdk::AuthNResolverClient;

let authn = hub.get::<dyn AuthNResolverClient>()?;

// Authenticate a bearer token
let result = authn.authenticate("eyJhbGciOiJSUzI1NiIs...").await?;
let security_context = result.security_context;
// security_context contains: subject_id, subject_tenant_id, token_scopes, bearer_token
```

## Configuration

The module is configured via the server's YAML config. Plugin selection is automatic based on GTS registration. Use the `static-authn` feature flag to compile in the development plugin.

## Writing a Plugin

Implement the `AuthNResolverPluginClient` trait from `cf-authn-resolver-sdk` and register it with a GTS instance ID derived from the `AuthNResolverPluginSpecV1` schema.

## Testing

```bash
cargo test -p cf-authn-resolver
```

## License

Apache-2.0
