Home → Architecture → Security Model

Security Model

Security is a property of the architecture, not a collection of optional features. What follows is the design side — how authentication, authorization, audit, deployment, and data protection are structured, and where the customer-side line falls.

Authentication

Every method authenticates against the same user record, issues the same JWT session, and lands in the same audit chain. Enable one or more per tenant.

• Local accounts — email + password, bcrypt-hashed. Password policy configurable per tenant.
• WebAuthn / FIDO2 — YubiKey or platform authenticators. Per-user credential management under Preferences.
• PKI / CAC — smart-card client certificates via nginx front-end. Configured through the admin panel; nginx conf is generated on the way in.
• LDAP — bind against a customer directory (Active Directory or general LDAP). Group-to-role mapping.
• OIDC — PKCE flow. Federation with OIDC-native identity providers.

Authorization

Role-based access

Nine application roles — admin, author, qa, peer_review, cir_controller, graphics_editor, program_manager, customer, viewer — plus sysadmin as a separate capability for offline-update flows. Every endpoint enforces role at the API layer, not just the UI.

Project isolation

Each project is a self-contained copy — documents, graphics, applicability filters, BREX rules, deliveries, membership. Users can have different roles on different projects; cross-project data does not flow unless an admin explicitly groups projects via a TM Family (which is read-only across the family boundary).

Least privilege

Users have a primary role plus zero or more granted roles. A granted role is available but not always-on: activate it through sudo-style temporal elevation for a time-boxed window. Elevation shows as a countdown chip in the UI, drops automatically at expiry, and every action taken under elevation carries the elevation event id in the audit record. Pattern is deliberately Unix-sudo-shaped.

Audit

HMAC-chained audit log

Every state-changing action writes to audit_log. Rows carry the acting user, timestamp, event type, resource, details, IP, session id, and the caller's role_at_time plus elevation_event_id if elevation was active. Each row's record_hash is an HMAC-SHA256 chained to the prior row's hash — deleting or editing a row breaks the chain and is detectable on audit read. Append-only and self-verifying.

Export

Read access: admin only. Filters: event_type, user_id, user_email, ip_address, since/until, free-text search. Export as newline-delimited JSON.

SIEM integration

NDJSON export is designed for direct ingestion into a SIEM. Splunk, Elastic, and Sentinel all accept NDJSON on file-tail or forwarder input; the schema is stable across releases.

Deployment

• On-premises — bundle installer on customer hardware. Same product on customer-managed VMs, bare metal, or VMware.
• Air-gapped — no network dependencies at runtime. Install and updates travel as signed offline bundles. See Airgap deployment.
• Zero outbound connections by default — the app makes no outbound HTTP in the default configuration. No telemetry, no license phone-home, no auto-update. The only outbound capability the app itself has is a dependency-CVE check (opt-in). An SMTP relay for notifications, if you want one, is configured explicitly. Everything else stays on the network you put it on.
• Customer-controlled infrastructure — the customer owns the host, the network, the storage, and the operating system. Ironmark ships an application; the deployment environment is yours.

Data protection

• TLS — from browser to nginx via the customer's cert (Let's Encrypt, customer-supplied CA, or self-signed for airgap). Programs on Let's Encrypt or another ACME provider will have the ACME client on the host make its own outbound calls to renew certs — that's a customer-configured TLS choice, not the application. Internal traffic (nginx → gunicorn → MySQL) is loopback.
• Session management — JWT with short TTL, backed by an active-session registry. Revocation is immediate. Admin panel sessions live in-memory intentionally — a service restart invalidates them, matching the airgap posture. Never persisted to disk.
• Support package encryption — support packages produced from the app can be tier-encrypted (customer-key or vendor-key) with a one-way sanitize option that strips or randomizes program-identifying content before packaging.
• Backups — standard MySQL dump against the ironmark schema plus rsync of /opt/ironmark/app/data/. Restore is the reverse. Admin panel's offline-update flow requires backup affirmation before applying migrations.
• Secrets — DB credentials, license pubkey, session signing key, auth-provider client secrets all live in /opt/ironmark/env/*, root-owned, systemd-injected as EnvironmentFile. Never in the DB.

Compliance

Compliance for a program is a function of both the application and the environment it runs in. We can be specific about the application side.

NIST SP 800-171 application-side controls are implemented; the infrastructure-side controls remain the responsibility of the deployment environment. Programs targeting FedRAMP or DoD IL levels typically cite these application controls directly and document the environment side separately.

← Back to Architecture