feat(agent): enrichissement ONVIF authentifié côté agent — pool chiffré via config #49
No reviewers
Labels
No labels
bug
chore
design
dx:ci
dx:database
dx:dotnet
dx:infra
dx:security
dx:tests
dx:ui
etape-1
etape-2
etape-3
etape-4
etape-5
etape-6
etape-7
feature
priority-high
priority-low
priority-medium
security
spec
tech-debt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
nonobis/Heimdall!49
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/camera-discovery-agent"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What
L'enrichissement ONVIF authentifié est déplacé côté agent. Le pool de credentials du site (login/mdp) est exposé à l'agent via
GET /api/settings/agent/{id}sous forme d'enveloppe AES-256-GCM (AgentCredentialEnvelope, clé dérivée du SHA-256 de l'API key) — déchiffrable uniquement côté agent.NetworkCameraScannertenteGetDeviceInformationavec chaque couple du pool (PasswordDigest puis PasswordText) et remonte des devices déjà identifiés (fabricant/modèle ONVIF +CredentialLabel). Le central persiste et marque le credential utilisé (LastUsedAt) — plus aucun appel réseau ONVIF côté central.Why
Le central n'est généralement pas sur le réseau des caméras : les appels ONVIF authentifiés qu'il faisait après réception des devices bruts échouaient. L'agent, lui, est sur le sous-réseau des caméras — c'est lui qui doit porter l'auth. Enrichissement et identification se font au moment du scan, avant la remontée.
How
AgentCredentialEnvelope(Application/Security) : AES-256-GCM, clé = SHA-256 de l'API key ; central chiffre (via l'ApiKeyHashstocké), agent déchiffre (via sa clé en clair).GetEffectiveAgentConfigQuery: ajoutediscovery.credentials(pool chiffré) au dict de config.SettingsController.GetEffectiveConfig: accepte l'API key agent (vérification par site) en plus du JWT admin — corrige au passage un 403 latent sur cet endpoint.NetworkCameraScanner: probe ONVIF authentifié avec le pool (anonyme d'abord, puis chaque couple).AgentCredentialStore(mémoire, jamais sur disque) : reçoit le pool déchiffré parConfigReceiverService, lu parAgentDiscoveryService.CameraDiscoveryService: suppression de l'enrichissement réseau ; persistance +MarkUsedviaCredentialLabel; vendor déduit du fabricant ONVIF remonté.SitesController: broadcastConfigReloadaprès add/delete credential pour que les agents re-fetch leur pool.Testing
dotnet build Heimdall.slnx: 0 erreur / 0 warning.Breaking Changes
Aucun changement de schéma (pas de migration). Comportement API :
GET /api/settings/agent/{id}accepte désormais l'API key agent (accès élargi au cas d'usage prévu).Related to #48
Le central ne fait plus d'appels réseau ONVIF pour les découvertes soumises par les agents : hors du réseau caméras, ces appels échouent. Le pool de credentials du site est désormais exposé à l'agent via GET /api/settings/agent/{id} sous forme d'enveloppe AES-256-GCM (clé dérivée du hash SHA-256 de l'API key de l'agent), déchiffrable uniquement côté agent. NetworkCameraScanner tente GetDeviceInformation avec chaque couple du pool (PasswordDigest puis PasswordText) et remonte des devices déjà identifiés (fabricant/modèle ONVIF + label du credential utilisé). Le central persiste et marque le credential utilisé (LastUsedAt). SettingsController.GetEffectiveConfig accepte l'API key agent (vérification par site) en plus du JWT admin ; SitesController broadcast ConfigReload après add/delete credential. Tests : Application 346, Agent 108, Infrastructure 143 (hors Testcontainers), Web.Tests 213 — nouveaux bUnit DiscoveriesPage (5) et SiteDetail credentials (4). Fixes #48