23 lines
1.6 KiB
Markdown
23 lines
1.6 KiB
Markdown
# Key Vault and Provider Registry
|
|
|
|
This internal service is the credential boundary between Authentik identities and Xiteng Chat. It stores
|
|
Backend Provider credentials with AES-256-GCM envelope encryption. Every credential has a random data-encryption
|
|
key; the master key wraps only those data keys, so master-key rotation is independent of provider-key rotation.
|
|
|
|
`providers.json` is the built-in Provider Catalog. Administrators can add Custom Providers in SQLite without
|
|
editing the built-in file. A provider declares its API protocol, frontend/backend connection type, endpoint,
|
|
optional proxy, authentication shape, default-model preference, and a model-discovery type plus URL. The Vault
|
|
does not store model lists; Xiteng Chat fetches them dynamically from each configured Provider.
|
|
|
|
The service is internal-only. `xiteng.site` and `xiteng-chat` sign requests with a dedicated service token after
|
|
Authentik checks. The Vault independently treats only the exact username `liooil` as an administrator. Other
|
|
identities can access only records whose `(issuer, sub)` pair matches their session.
|
|
|
|
Normal metadata APIs never return plaintext. The dedicated `/v1/resolve` endpoint is restricted to the exact
|
|
service name `xiteng-chat`; it decrypts one active Backend Credential owned by the signed user and returns it to
|
|
the Chat server for one provider request. Frontend Provider credentials never enter this service and remain in
|
|
the browser's IndexedDB.
|
|
|
|
Xiteng Chat connects directly: Backend Providers from the Chat server, Frontend Providers from the browser.
|
|
Vault audit records cover credential lifecycle, verification, reassignment, resolution, and Custom Provider changes.
|