Aller au contenu principal

SAML Private Key Hardening

Scope​

This guide applies to operators running Noxys API with SAML 2.0 SSO enabled (NOXYS_SAML_KEY_PATH set). It does not apply to OIDC-only deployments or to the managed SaaS tier where Noxys owns the key storage.

Threat model​

The SAML SP private key is used to sign AuthnRequest assertions and to decrypt IdP-encrypted responses. Compromise lets an attacker:

  • Forge authentication requests appearing to come from your Noxys tenant
  • Decrypt prior captured SAML responses if saved
  • Impersonate Noxys to your IdP

Key sensitivity is equivalent to your IdP's own signing key. Treat it as a Tier 0 secret: never checked into version control, never copied to developer workstations, never transmitted over unencrypted channels.

Filesystem hardening (current implementation)​

The Noxys API loads the key from NOXYS_SAML_KEY_PATH (PEM encoded PKCS#1 or PKCS#8). The minimum operational controls:

ControlSettingRationale
File permissionschmod 0400Only owning user can read
File ownershipDedicated noxys service user, non-loginPrevents console access
Parent directory/etc/noxys/ with 0500 permsTamper-evident
FilesystemNot on tmpfs, not on NFSPersists across reboot, no network exposure
BackupEncrypted at rest with independent keySeparates encryption from key custody
Monitoringaudit inode accessDetect unauthorized reads

Example hardening procedure​

# Create dedicated service user (idempotent)
sudo useradd --system --no-create-home --shell /usr/sbin/nologin noxys

# Create directory with restricted permissions
sudo install -d -o noxys -g noxys -m 0500 /etc/noxys

# Install the key file
sudo install -o noxys -g noxys -m 0400 /path/to/saml-sp.key /etc/noxys/saml-sp.key

# Verify
sudo -u noxys cat /etc/noxys/saml-sp.key > /dev/null && echo "readable by noxys"
sudo -u nobody cat /etc/noxys/saml-sp.key 2>&1 | grep -q "Permission denied" && echo "not readable by others"

# Configure Noxys
export NOXYS_SAML_KEY_PATH=/etc/noxys/saml-sp.key

Audit logging​

Enable file access auditing on the key file:

sudo auditctl -w /etc/noxys/saml-sp.key -p rwa -k noxys-saml-key

Any read, write, or attribute change fires a kernel audit event tagged noxys-saml-key. Forward these events to your SIEM so that any access outside the expected Noxys API process triggers an alert.

Rotation​

  1. Generate a new key + cert pair (4096-bit RSA or P-384)
  2. Update your IdP with the new SP metadata (contains the new cert)
  3. Replace /etc/noxys/saml-sp.key atomically: 
    sudo install -o noxys -g noxys -m 0400 /tmp/new-saml-sp.key /etc/noxys/saml-sp.key.new
    sudo mv -f /etc/noxys/saml-sp.key.new /etc/noxys/saml-sp.key
    sudo systemctl restart noxys-api
  4. Verify first SSO login succeeds
  5. Destroy the old key material (shred or HSM destroy)

Rotation cadence: annual minimum, immediately on suspected compromise. This aligns with the cryptoperiod guidance in NIST SP 800-57 Part 1 Rev. 5 for private signature keys used in authentication contexts.

Cloud-managed alternatives (roadmap)​

Filesystem storage is the default but not the only supported model. The following providers are planned for future releases with a pluggable SAMLKeyProvider interface:

ProviderStatusTarget
AWS KMS (CMK wrap)Plannedv1.0
GCP KMS (Cloud KMS)Plannedv1.0
HashiCorp Vault (Transit)Plannedv1.0
Azure Key VaultPlannedv1.5
Hardware HSM (PKCS#11)Evaluatedv2.0

Deployments requiring KMS-backed keys today should run Noxys on a machine with full-disk encryption and tight network isolation, and plan to migrate once the provider interface ships.

Self-host vs managed​

On the Noxys managed SaaS tier (app.noxys.cloud), SAML keys are held by Noxys in internal KMS infrastructure documented under NDA as part of the Trust Center artefact bundle. Self-hosted deployments retain full custody of the key material and are responsible for implementing the controls in this guide.

Verification checklist for procurement​

When a CISO asks "how is your SAML signing key protected?", the answer for a hardened self-hosted deployment is:

  • Key file is 0400 owned by dedicated service user
  • Parent directory is 0500
  • File access is audited via auditd
  • Backups are encrypted with an independent key
  • Rotation procedure documented and tested annually
  • Migration path to KMS is on the vendor roadmap

References​