Home → Architecture → Security Model

Security Model

This page describes Ironmark's application-level security posture. Exact controls depend on the installed version, enabled authentication paths, reverse proxy, operating system, storage, and the customer's system boundary. It is product information, not a compliance certification.

Authentication

Ironmark supports local authentication plus optional enterprise identity paths. Enabled methods resolve users to Ironmark accounts and project roles. Individual identity-provider and CAC integrations require validation in the customer's environment.

• 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. Implemented; individual vendor integrations pending field validation against real customer environments.
• OIDC — PKCE flow. Federation with OIDC-native identity providers. Implemented; individual vendor integrations pending field validation against real customer environments.

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. Protected operations enforce authentication and applicable role checks at the API layer; the capability matrix is the bounded statement of implemented coverage.

Project isolation

Documents, graphics, and parts enforce project-access checks, and users may hold different project memberships. Other endpoint families have not yet been represented here as a universal project-isolation guarantee. TM Families provide selected read-only cross-project views within one instance.

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

Ironmark records selected authentication, authorization, administrative, controlled-workflow, publishing, and distribution events. Audit rows are HMAC-SHA256 chained so alteration or deletion within the recorded chain is detectable during verification. Ironmark does not claim that every user action or every API mutation is currently represented.

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

Administrators can export audit records as NDJSON for downstream processing. A customer should validate field mapping and retention against its chosen SIEM and installed Ironmark version.

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. Three outbound paths are possible and each stays off until you turn it on: a dependency-CVE check (opt-in), an SMTP relay for notifications (configured explicitly), and your identity provider (only if you configure OIDC). 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 — selected support-package tiers use AES-256-GCM. The optional sanitizer replaces selected identifiers and text but is not a proof of anonymization; preview and review remain required before release.
• 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.
• SBOM — an administrator can generate a CycloneDX inventory of the package classes currently supported by the SBOM generator. See FAQ 9.02 for its bounded coverage.

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.

Ironmark includes application features that may support a customer's NIST SP 800-171 control implementation. Control applicability, evidence sufficiency, inherited controls, assessment, and the compliance determination belong to the customer's defined system and security plan. Ironmark is not FIPS-140 validated or FedRAMP authorized.

← Back to Architecture