Skip to content

Generated SaaS Security

Target Architecture — Final-State Design

This page describes the security architecture generated into every SaaS Product. Authentication is provided by ConnectSoft.AuthorizationServerTemplate (OpenIddict); tenant isolation and SaaS security patterns come from the ConnectSoft.Extensions.Saas.* libraries. Security is generated by construction — not bolted on — so every product inherits the same hardened baseline.

Security in a generated product is defense in depth: authentication at the edge, authorization at every service, tenant isolation in every store and message, secrets only in Key Vault, and an immutable audit trail recording every sensitive action. Each control is generated from a shared, hardened template.

Authentication (OpenIddict)

  • Token issuance. The Authorization Server (ConnectSoft.AuthorizationServerTemplate, OpenIddict) issues OAuth2/OIDC tokens. Supported grants: authorization code + PKCE (interactive portals/mobile), client credentials (service-to-service), and refresh tokens.
  • Validation. The API Gateway validates signature, issuer, audience, and expiry on every request before routing; each service re-validates and extracts claims (sub, tenantId, scopes/permissions).
  • Federation. External identity providers (Entra ID, social, SAML) can be federated through OpenIddict for enterprise tenants.
  • Token contents. Tokens carry tenantId, user id, role/permission scopes, and edition entitlements, enabling stateless authorization downstream.

Authorization (RBAC + ABAC)

  • RBAC. Users hold Roles; roles grant Permissions (e.g. subscription.manage). Endpoint authorization checks the required permission scope from the token.
  • ABAC. Attribute-based checks refine RBAC with context: resource ownership, tenant match, edition entitlement, and data classification. Example: a user with report.read may only read reports within their own tenant and permitted categories.
  • Entitlement gating. Capabilities are additionally gated by the tenant's Edition entitlements, so authorization reflects both who you are and what your plan includes.
  • Policy enforcement. Authorization policies are generated consistently across services from the blueprint permission model.

Tenant isolation

  • Identity boundary. Every token carries tenantId; the gateway and each service reject requests whose route/resource tenant does not match the token's tenant (except platform-admin scopes on the Tenants resource).
  • Data boundary. The NHibernate global tenant filter injects tenantId predicates on every query (or routes to schema/database-per-tenant); handlers additionally assert the envelope tenantId. See data model.
  • Message boundary. Every event carries tenantId; consumers assert it before acting, and Service Bus subscriptions filter on cs-tenant-id.
  • Cache boundary. Redis keys are prefixed by tenantId; no cross-tenant cache reads are possible.

Secret handling

  • Key Vault only. Connection strings, signing keys, integration credentials, and webhook secrets live exclusively in Azure Key Vault.
  • References, not secrets. Aggregates (IntegrationConnection, WebhookSubscription, secret-typed ConfigurationSetting) store a SecretReference pointer — never the secret value.
  • Managed identity. Services authenticate to Key Vault and data stores via managed identities; no secrets in code, config files, or images.
  • Rotation. Secrets and signing keys rotate on a schedule; services re-read on rotation without redeploy.

Audit

  • Immutable trail. Every authentication, authorization decision, and sensitive mutation emits AuditEntryRecorded, persisted append-only and archived to immutable Blob (see aggregate roots).
  • Correlated. Each AuditEntry stores TraceId, so security events correlate with the full request and event chain.
  • Tamper-evident. Audit records are write-once; the archive container is WORM-configured.

Threat model & mitigations

Threat Mitigation
Cross-tenant data access Token tenantId enforcement + NHibernate global filter + handler assertion + tenant-prefixed cache
Token theft / replay Short-lived access tokens, refresh rotation, PKCE, audience/issuer validation
Privilege escalation Server-side RBAC/ABAC; system roles/permissions immutable; entitlement gating
Secret leakage Key Vault-only secrets, managed identity, SecretReference indirection, no secrets in images
Injection / malformed input Generated input validation, parameterized NHibernate queries, schema validation on report/config
Poison messages / replay abuse Idempotency on eventId, dead-letter quarantine, bounded retry
Webhook abuse / SSRF HTTPS-only callbacks, signed payloads, allowlist + egress controls
Denial of service Per-tenant gateway rate limiting, autoscaling, circuit breakers on integrations
Audit tampering Append-only store + immutable Blob archive

Implementation Notes

Security controls feed the factory's Governance, Security & Compliance platform: audit events and policy decisions from the running product are surfaced as compliance evidence, closing the governance loop from intent to runtime.

How security contributes to the pillars

  • Traceability — audit entries carry traceId; every authz decision is correlatable to the originating request.
  • Reusability — auth, isolation, and secret patterns are generated from shared hardened templates and libraries.
  • Autonomy — the security baseline is generated automatically; agents do not hand-write auth wiring.
  • Governance — RBAC/ABAC, immutable audit, and policy gating are first-class and feed factory compliance.
  • Observability — security metrics (auth failures, denials, rate-limit hits) are emitted and dashboarded.
  • Multi-tenant scale — tenant isolation is enforced at identity, data, message, and cache layers simultaneously.