Identity Access (Per-App SSO Authorization)

Authorize applications to use globally defined SSO adapters. Identity artifacts are never provided to apps unless explicitly allowed here (least privilege).

What You'll Learn

• How to authorize per-app access to SSO artifacts
• Adapter references and configuration
• Token scoping for token injection adapters
• Examples for common apps (RDP, SSH clients, modern API clients)

Where it’s defined

• Global adapter definitions: configuration.identity.identityAdapters
• Per-app authorization: apps[].modifications.identityAccess[]
• Per-launch profile (optional override): apps[].profiles[].identityAccess[]

Related

• Global Configuration (adapters, MFA, claims mapping)
• ABAC authorization requirements (user/context)
• Data Motion (classification-aware DLP)
• Audit Trails (SSO audit level)

---

Concept

• Adapters define “how” identity is adapted to the runtime (Kerberos/WIA, certificate/virtual smart card, SSH key injection, token injection).
• Apps opt-in via identityAccess entries, referencing adapterRef by id.
• For token injection, optional tokenParameters can further constrain tokens at launch (audience/scopes).

Adapter types

• windowsIntegratedAuth — Kerberos/NTLM/GSSAPI passthrough
• virtualSmartCard — PIV/CAC certificate presentation
• sshKeyInjection — SSH key provisioning (file or agent)
• tokenInjection — OIDC/SAML/username artifacts to file (preferred); env/registry (discouraged)

---

Schema

apps[].modifications.identityAccess[]

{
  "enabled": true,
  "adapterRef": "adapter-id",                  // must match configuration.identity.identityAdapters[].id
  "tokenParameters": {
    "requiredAudience": "api://my-service",    // tokenInjection only (optional)
    "requiredScopes": ["api.read"]             // tokenInjection only (optional)
  }
}

Notes

• When disabled or omitted, the app receives no SSO artifacts for that adapter.
• tokenParameters apply only to tokenInjection adapters; ignored for other types.
• All adapter behavior and security constraints are defined under configuration.identity.identityAdapters.

---

Examples

RDP Client (mstsc.exe) — WIA and PIV

{
  "apps": [
    {
      "id": "rdp-client",
      "action": "allow",
      "modifications": {
        "identityAccess": [
          { "enabled": true, "adapterRef": "wia-passthrough" },
          { "enabled": true, "adapterRef": "piv-passthrough" }
        ]
      }
    }
  ]
}

SSH Clients (MobaXterm, WinSCP, Cygwin) — SSH key and optional WIA (GSSAPI/Kerberos)

{
  "apps": [
    {
      "id": "ssh-clients",
      "action": "allow",
      "modifications": {
        "identityAccess": [
          { "enabled": true, "adapterRef": "derived-ssh-key-file" },
          { "enabled": true, "adapterRef": "wia-passthrough" }
        ]
      }
    }
  ]
}

Modern API Client — OIDC access token with scoped audience

{
  "apps": [
    {
      "id": "modern-client",
      "action": "allow",
      "modifications": {
        "identityAccess": [
          {
            "enabled": true,
            "adapterRef": "oidc-access-token-file",
            "tokenParameters": {
              "requiredAudience": "api://my-service",
              "requiredScopes": ["api.read"]
            }
          }
        ]
      }
    }
  ]
}

---

Operational Guidance

• Keep adapters disabled by default; authorize only what each app needs.
• Combine with ABAC in apps[].authorization.requirements to ensure only appropriate users/contexts can launch the app (e.g., usPersonStatus=verified, compliant host).
• Set configuration.identity.ssoAuditLevel according to enterprise logging requirements (minimal | standard | verbose).
• Use securityOptions on adapters to restrict artifact exposure (restrictToTargetProcess) and require explicit acknowledgment for weaker mechanisms (acknowledgeInsecureMechanism: true when applicable).
• Token injection security: Prefer file targets with memory-backed storage and strict ACLs; avoid env/registry due to leakage risk. If env/registry are required for legacy apps, set adapter.securityOptions.acknowledgeInsecureMechanism: true and restrictToTargetProcess: true. Future releases will add secure IPC/keyring-backed delivery to eliminate weaker surfaces.