Skip to content

Security

Target Architecture — Final-State Design

This page describes the final-state security model of the Marketplace Platform. It builds on the factory authorization server, ConnectSoft.Extensions.WebSecurity, and the Governance, Security & Compliance platform. Because the Marketplace distributes installable code into tenants, publisher trust and asset signing are first-class controls.

The Marketplace is a supply chain for installable assets, so its threat surface is the supply chain itself: who may publish, what gets distributed, who may install, and how integrity is guaranteed end to end. Security is enforced at the edge (authn/authz), in the domain (invariants), at the data layer (tenant isolation), and across the lifecycle (signing, scanning, audit).

Authentication

  • OAuth2 / OpenID Connect — every API and UI call carries a bearer token issued by the factory authorization server (AuthorizationServerTemplate). Tokens carry tenantId, subject, scopes, and (for publishers) publisherId.
  • Service identity — inter-service calls use workload identities with mutual TLS in the service mesh; internal APIs are not reachable from the public gateway.
  • Agent identity — Agent Mesh callers present a delegated token scoped to a task- id, so autonomous installs are attributable to a specific agent task.

Authorization

Authorization is scope-based plus tenant-scoped roles (see APIs):

Scope Grants Additional check
marketplace.read Browse, view detail, search Catalog visibility for tenant
marketplace.install Install assets Project access + valid License for paid assets
marketplace.publish Publish assets, release versions publisherId must be Verified and not suspended
marketplace.review Submit reviews Verified install of the asset
marketplace.admin Manage publishers, pricing, trust tiers Tenant admin role

Domain invariants enforce authorization-relevant rules independently of the edge (e.g. an unverified publisher cannot release a signed version, a withdrawn asset cannot be installed) — defense in depth.

Tenant isolation

  • Every store row, query, event, and cache key is tenantId-scoped; NHibernate global filters and handler-level tenant guards prevent cross-tenant access (see Data Model).
  • Shared/public assets are modeled under a platform tenant and exposed via catalog visibility rules, never by relaxing row filters.
  • Package storage uses per-tenant path prefixes/containers where required; signed package URLs are short-lived and tenant-scoped.

Secret handling

  • Azure Key Vault holds all secrets: publisher signing keys (referenced by SigningKeyRef, never stored in SQL), package store credentials, billing integration secrets, and service credentials.
  • Secrets are retrieved via managed identity at runtime; nothing secret is logged, returned by APIs, or shown in the UI.
  • Configuration follows the Options pattern; secret material is injected from Key Vault, not from app settings.

Publisher trust

  • Publishers have a verification status (Unverified → Pending → Verified → Suspended) and a trust tier (T0 community → T3 first-party ConnectSoft).
  • Trust tier governs publishing friction: low-tier publishers require manual policy approval and stricter quality gates; high-tier publishers may auto-approve within policy.
  • Reputation (from reviews, install success, and incident history) feeds trust-tier review; sustained quality failures or security incidents can suspend a publisher, blocking new installs of their assets.

Asset signing and integrity

  • Every released AssetPackage is signed with the publisher's Key Vault-backed key; AssetVersion.Signed and Signature record this.
  • Packages are content-hash addressed; ContentHash is verified on every read/install, so tampering is detectable.
  • Installation refuses unsigned or hash-mismatched packages; the installation flow validates signature and hash before Applying.
  • Quality scanning (AssetQualityScanWorker) runs security checks (secret/malware/vulnerability heuristics, policy compliance) before release.

Audit

  • Every state change emits a canonical event with tenantId, traceId, correlationId, and actor (requestedBy/publisherId), providing a complete, immutable audit trail.
  • Publishing, installation, license grant/revoke, and trust-tier changes are auditable end to end and ingested by Governance and the Knowledge Platform.
  • Provenance (AssetInstallation → version → package → publisher → license) answers "what was installed, from where, by whom, under what license" for any tenant.

Threat model

Threat Mitigation
Malicious or tampered package Signing + content-hash verification on read/install; quality/security scan gate before release
Unauthorized publishing Publisher verification + marketplace.publish scope + signed-version invariant
Cross-tenant data access Tenant-scoped filters, guards, and storage prefixes; defense-in-depth invariants
Privilege escalation via install Project-access check + license check + compatibility gate before apply
Secret leakage Key Vault-only secrets, managed identity, no secret logging/return
Dependency confusion / conflict Deterministic dependency resolution with conflict detection before install
Reputation gaming (fake reviews) Reviews gated on verified install; moderation and reputation scoring
Supply-chain replay/poisoning Immutable, versioned packages; idempotent sagas; dead-letter preservation for forensic replay

Continue to Observability, Workflows, and Governance, Security & Compliance.