Global Configuration

Centralized, policy-authored settings that establish the global security posture, identity/SSO integrations, and data classification mappings consumed elsewhere in the policy.

What You'll Learn

• Identity and authentication policy (MFA, re-auth, claims mapping)
• SSO Identity Adapters (how Launcher identity is adapted into app runtimes)
• Security posture: FIPS, external KMS, and host attestation (ZTA)
• Data classification integration and mappings for content-aware DLP

Where it’s defined

• configuration.identity — identity, authentication, and SSO adapters
• configuration.security — cryptography and host attestation
• configuration.dataClassification — provider integration and label mappings

Related

• ABAC authorization using normalized claims
• Data-motion rules using classifications
• Audit Trails (CMMC AU posture)
• Application approval and visibility

---

Identity and Authentication (configuration.identity)

Defines authentication requirements (e.g., MFA), normalized claims for ABAC, session policy, and globally available SSO adapters that apps can request via identityAccess.

Example

{
  "configuration": {
    "identity": {
      "authenticationPolicy": {
        "defaultProviderConfigRef": "platform-idp-azuread-gov",
        "mfaPolicy": {
          "mode": "enforced",                      // disabled | enabled | enforced
          "allowedMethods": ["fido2","certificate","smartcard"]
        },
        "reauthFrequencyHours": 8
      },
      "claimsMapping": {
        "usPersonStatus": "ext.usPersonVerified",
        "clearanceLevel": "ext.securityClearance"
      },
      "sessionPolicy": {
        "inactivityTimeoutMinutes": 15
      },
      "identityAdapters": [
        // See “Identity Adapters (SSO Strategies)” below
      ],
      "ssoAuditLevel": "standard"                   // minimal | standard | verbose
    }
  }
}

Notes

• claimsMapping provides stable, normalized attribute keys referenced by apps[].authorization.requirements.userAttributes.
• ssoAuditLevel controls verbosity of SSO-related audit entries.

Identity Adapters (SSO Strategies) (configuration.identity.identityAdapters[])

Defines how the Launcher’s identity context is adapted into the container runtime (least-privilege; opt-in per app via apps[].modifications.identityAccess).

Shape

{
  "id": "adapter-id",                  // kebab-case; referenced by apps[].modifications.identityAccess[].adapterRef
  "displayName": "Adapter Name",
  "type": "adapterType",               // tokenInjection | windowsIntegratedAuth | virtualSmartCard | sshKeyInjection
  "configuration": { /* type-specific */ },
  "securityOptions": {
    "restrictToTargetProcess": true,
    "acknowledgeInsecureMechanism": false
  }
}

Adapter examples

• windowsIntegratedAuth (Kerberos/NTLM/GSSAPI)

{
  "id": "wia-passthrough",
  "type": "windowsIntegratedAuth",
  "configuration": { "mode": "enabled" }          // enabled | constrained
}

• sshKeyInjection (file or agent)

{
  "id": "derived-ssh-key-file",
  "type": "sshKeyInjection",
  "configuration": {
    "keySourceRef": "user-session-derived-ssh-key",
    "targetType": "file",                          // file | sshAgent
    "filePath": "%USERPROFILE%\\\\.ssh\\\\id_rsa",
    "storageType": "memoryBacked"                  // diskBacked | memoryBacked
  }
}

• virtualSmartCard (PIV/CAC)

{
  "id": "piv-passthrough",
  "type": "virtualSmartCard",
  "configuration": {
    "presentationMode": "virtualCard",             // virtualCard | storeInjection
    "certificateSource": "hostCertificateStore",   // derived | hostCertificateStore
    "destinationStore": "CurrentUser_My",
    "filters": [
      { "type": "issuerCN", "pattern": "US Government PIV Issuer CA", "patternType": "exact" }
    ]
  }
}

• tokenInjection (OIDC/SAML/Username)

{
  "id": "oidc-access-token-file",
  "type": "tokenInjection",
  "configuration": {
    "artifactType": "accessToken",                 // accessToken | idToken | samlAssertion | username
    "targetType": "file",                          // file (preferred) | env (discouraged) | registry (discouraged; vendor-specific)
    "filePath": "%LOCALAPPDATA%\\\\MyApp\\\\sso.token",
    "storageType": "memoryBacked"                  // diskBacked | memoryBacked
  }
}

Security guidance — tokenInjection targets

• Prefer targetType: "file" with storageType: "memoryBacked" where supported. Create ephemeral files with restrictive ACLs and auto-delete on process exit.
• Avoid targetType: "env" and "registry". These surfaces are prone to leakage via child processes, crash dumps, and diagnostics. If you must use them for legacy app compatibility, set securityOptions.acknowledgeInsecureMechanism: true and consider ssoAuditLevel: "verbose".
• Set securityOptions.restrictToTargetProcess: true to limit artifact exposure to the launched process tree where supported.
• Scope tokens tightly (short lifetimes, least scopes/audience) and avoid persisting refresh tokens.
• Forward-looking: upcoming versions will prioritize secure IPC hand-offs and native OS keyrings to avoid materializing tokens in env/registry.

Security options

• restrictToTargetProcess: confine injected artifacts to the launched process tree where supported.
• acknowledgeInsecureMechanism: must be true when using known weak surfaces (e.g., plain environment variables); enables auditable warnings.

Apps must explicitly opt-in per adapter via: apps[].modifications.identityAccess[].adapterRef. See: Identity Access (SSO).

---

Security Posture and Cryptography (configuration.security)

Centralizes FIPS enforcement, key management, and host integrity validation.

Example

{
  "configuration": {
    "security": {
      "cryptography": {
        "fipsMode": "enforced",                     // disabled | enabled | enforced
        "keyManagement": {
          "integrationMode": "externalKms",         // none | platform | externalKms
          "kmsProviderConfigRef": "platform-kms-aws-govcloud",
          "customerManagedKeyRef": "key-id-12345"
        }
      },
      "hostAttestation": {
        "mode": "enforce",                          // disabled | audit | enforce
        "providerConfigRef": "platform-attestation-crowdstrike-zta",
        "requirements": {
          "requireManagedDevice": true,
          "minimumComplianceScore": 75,
          "requireActiveThreatProtection": true
        },
        "onFailure": "denyAccess"                   // denyAccess | notify | auditOnly
      }
    }
  }
}

Notes

• hostAttestation enables contextual constraints used by ABAC (e.g., “requireCompliantHost”).
• Use enforce modes to block access when posture cannot be validated.

---

Audit Configuration

Security Critical — Fail-Closed Audit

Setting failurePolicy.onFailure: block ensures that if the audit subsystem fails (disk full, SIEM unreachable), sensitive operations are denied immediately. This prevents "blind" actions during logging outages, satisfying strict compliance requirements (e.g., CMMC AU-5).

---

Data Classification Integration (configuration.dataClassification)

Integrates classification providers (e.g., Microsoft Purview MIP) and maps external labels to normalized values used in policy authoring and runtime DLP.

Example

{
  "configuration": {
    "dataClassification": {
      "onClassificationFailure": "deny",
      "onUnknownClassification": "deny",
      "providers": [
        {
          "id": "corp-purview",
          "type": "purview",
          "capabilities": ["document", "clipboard", "window"],
          "confidenceThreshold": 0.8,
          "cacheTtlSeconds": 30,
          "connection": {
            "tenantId": "{{CRED:Purview:tenantId}}",
            "clientId": "{{CRED:Purview:clientId}}",
            "clientSecret": "{{CRED:Purview:clientSecret}}"
          }
        }
      ],
      "mappings": [
        { "providerId": "corp-purview", "externalLabelId": "uuid-...", "normalized": ["CUI//SP-CTI"] },
        { "providerId": "corp-purview", "externalLabelId": "uuid-...", "normalized": ["ITAR"] }
      ],
      "normalizedVocabulary": ["ITAR", "CUI", "CUI//SP-CTI", "CUI//SP-EXPT", "CUI//SP-PRVCY", "EAR", "EAR99"]
    }
  }
}

Notes

• onClassificationFailure controls behavior when classification providers are unreachable or return errors. For ITAR/CMMC environments, use "deny".
• onUnknownClassification controls behavior when content has no classification or classification is indeterminate. For ITAR/CMMC environments, use "deny".
• providers[].id is a stable identifier referenced by mappings[].providerId.
• mappings[].normalized uses the standard CUI marking format (e.g., CUI//SP-CTI). See: Normalized Classification Vocabulary.
• Use runtime.dataMotion.rules[].match.classifications to implement content-aware DLP. See Data Motion.

---

Approval Workflows (configuration.launch.runtime.approval)

Define global approval workflows that gate operations such as appLaunch and future in-app operations. Use this section when you want applications discovered on the desktop to be visible but require an approval workflow before they can run in the Secure Sandbox runtime.

Example

{
  "configuration": {
    "launch": {
      "runtime": {
        "approval": {
          "workflows": [
            {
              "id": "manager-approval-app-launch",
              "type": "accessRequest",                 // accessRequest | policyChange | custom
              "operations": ["appLaunch"],
              "providerRef": "manager-email-approval", // integration-specific identifier
              "description": "Manager approval for high-risk applications"
            }
          ],
          "defaults": {
            "appLaunchWorkflowRef": "manager-approval-app-launch"
          }
        }
      }
    }
  }
}

Fields

• configuration.launch.runtime.approval.workflows[]:
  • id (string, required): Stable identifier for the workflow; referenced by apps[].authorization.approval.workflowRef.
  • type (string, required): "accessRequest" | "policyChange" | "custom".
    • Use "accessRequest" for runtime access approvals (for example, appLaunch).
    • Use "policyChange" when coordinating with change-management flows (separate from audit.changeRequests).
  • operations (string[], optional): Logical operation identifiers this workflow applies to (for example, "appLaunch", "appOperation.crm.exportSensitiveData").
  • providerRef (string, optional): Opaque reference to an integration or workflow provider configuration (email, ticketing, webhook, custom service).
  • description (string, optional): Human-readable description for administrators.
• configuration.launch.runtime.approval.defaults:
  • appLaunchWorkflowRef (string, optional): Default workflow id for appLaunch when apps[].authorization.approval.workflowRef is omitted.

Operational guidance

• Define one or more workflows under configuration.launch.runtime.approval.workflows and reference them from apps[].authorization.approval to require approval before launch.
• Use authorization.approval.reuse to control how long approvals remain valid (per launch, per session, or per user/app), balancing security with usability.
• Approval events are emitted under the authz and workflow.lifecycle categories. See: Audit Trails.