Appearance

Authorization and Visibility ​

Control what appears in the Applications tab and which executables are allowed to launch.

What You'll Learn

  • Authorize applications using allow policies (allowlist model)
  • Keep apps visible or hide them while still enabling file association targets
  • Understand how priority affects outcomes when multiple policies match

Authorization (Allowlist) ​

A launch is permitted only if at least one enabled application policy with action: "allow" matches the executable discovered from Start Menu/Desktop shortcuts and any additional authorization requirements (ABAC and optional approval) succeed.

Security Rule — Deny Always Wins

If any matching application policy has action: "deny", the launch is blocked, even if one or more matching policies have action: "allow".

Use deny sparingly and deliberately (for example, to enforce global blocks on high-risk executables). Once a deny matches, the app is neither visible nor launchable.

  • If no allow policy matches, the application is not launchable and will not appear in the Applications tab.
  • Matching is performed against discovered shortcuts and the resolved executable; matchers can include shortcut name, target path, arguments, and high-assurance identity (publisher certificate, file hash, version).

Tip: Use matchAny to express OR across alternatives; use matchAll for AND logic.

Minimal allow example:

json
{
  "id": "allow-chrome",
  "displayName": "Allow Chrome",
  "enabled": true,
  "priority": 200,
  "matchAll": [
    { "type": "targetPath", "pattern": ".*\\\\chrome\\.exe$", "patternType": "regex" }
  ],
  "action": "allow"
}

Additional example (OR across browsers using matchAny + glob):

json
{
  "id": "allow-chromium-browsers",
  "displayName": "Allow Chrome or Edge",
  "enabled": true,
  "priority": 200,
  "matchAny": [
    { "type": "targetPath", "pattern": "**\\\\chrome.exe", "patternType": "glob" },
    { "type": "targetPath", "pattern": "**\\\\msedge.exe", "patternType": "glob" }
  ],
  "action": "allow"
}

Matcher Evaluation Semantics ​

  • Logical AND (matchAll): All items must evaluate to true.
  • Logical OR (matchAny): At least one item must evaluate to true.
  • Nesting: Groups can be nested.
  • Rule: Only one of matchAll or matchAny can be present at any level.
  • There is no negate flag. Use regex constructs (for example, negative lookahead) when exclusion is required; prefer readable positive matches.
  • When multiple allow policies match, merges and tie-breaks follow priority (descending), then id (alphabetical). See: Merging & Precedence
  • For detailed guidance and examples (boolean logic semantics and matchAll/matchAny), see: Matchers & Patterns (boolean logic semantics)
  • Publisher certificate matching: specify the certificate field via the optional field on publisherCertificate (thumbprint, subjectCN, issuerCN, subjectDN, issuerDN). See: Matchers & Patterns (publisherCertificate)

Additional Matcher Examples ​

Example (OR across items):

json
{
  "id": "allow-putty-suite",
  "displayName": "Allow PuTTY Suite",
  "enabled": true,
  "priority": 200,
  "matchAny": [
    { "type": "targetPath", "pattern": ".*\\\\putty\\.exe$", "patternType": "regex" },
    { "type": "targetPath", "pattern": ".*\\\\psftp\\.exe$", "patternType": "regex" },
    { "type": "targetPath", "pattern": ".*\\\\pageant\\.exe$", "patternType": "regex" },
    { "type": "targetPath", "pattern": ".*\\\\puttygen\\.exe$", "patternType": "regex" }
  ],
  "action": "allow"
}

Contextual Authorization (ABAC) ​

Augment allow policies with attribute- and context-based constraints. Attributes come from configuration.identity.claimsMapping and are referenced by normalized keys. Context may include geo and host posture (derived from configuration.security.hostAttestation).

Example

json
{
  "apps": [
    {
      "id": "itar-engineering-suite",
      "displayName": "ITAR Engineering Suite",
      "enabled": true,
      "priority": 300,
      "matchAll": [
        { "type": "targetPath", "pattern": "**\\\\itarsuite.exe", "patternType": "glob" }
      ],
      "action": "allow",
      "authorization": {
        "requirements": {
          "userAttributes": [
            { "attribute": "usPersonStatus", "allowedValues": ["verified"] }
          ],
          "contextConstraints": {
            "allowedGeos": ["US"],
            "requireCompliantHost": true
          }
        }
      }
    }
  ]
}

Notes

  • userAttributes.attribute must reference a key defined under configuration.identity.claimsMapping (for example, "usPersonStatus": "ext.usPersonVerified").
  • requireCompliantHost relies on host posture signaled by configuration.security.hostAttestation (mode: "audit" or mode: "enforce"). When posture is non-compliant and enforce semantics apply, the launch is denied.
  • ABAC complements the allowlist matcher model; an allow policy must still match the executable or its shortcut.

Evaluation order

    1. A matching enabled policy with action: "allow" must succeed.
    1. apps[].authorization.requirements are evaluated (userAttributes and contextConstraints). Any failure denies launch (fail-closed under enforce modes).
    1. If apps[].authorization.approval.mode is configured (for example, "required"), an approval workflow must succeed before appLaunch is allowed. Approval workflows are defined under configuration.launch.runtime.approval and referenced by authorization.approval.workflowRef.
    1. If both allow and deny policies match, deny takes precedence. See: Deny vs Allow precedence
  • Workspace/profile scoping remains unchanged; ABAC is additive to existing scope filters.

Approval-Gated Applications ​

Use apps[].authorization.approval when you want an application to be discoverable and visible, but not automatically approved for use. Instead, a launch into the Secure Sandbox runtime triggers an approval workflow and generates audit events.

Example (approval required before launch):

json
{
  "apps": [
    {
      "id": "sensitive-engineering-tools",
      "displayName": "Sensitive Engineering Tools",
      "enabled": true,
      "priority": 400,
      "matchAll": [
        { "type": "targetPath", "pattern": "C:\\\\Tools\\\\Sensitive\\\\**.exe", "patternType": "glob" }
      ],
      "action": "allow",
      "authorization": {
        "requirements": {
          "userAttributes": [
            { "attribute": "usPersonStatus", "allowedValues": ["verified"] }
          ]
        },
        "approval": {
          "mode": "required",
          "workflowRef": "manager-approval-app-launch",
          "reuse": {
            "policy": "perUserPerApp",
            "ttlSeconds": 86400
          }
        }
      }
    }
  ]
}

Semantics

  • The app is still governed by the allowlist model and ABAC checks.
  • When a user selects the app in Applications and attempts to launch, the runtime evaluates authorization.approval:
    • If mode: "required" and no valid approval token exists under the configured reuse rules, the client triggers the configured workflow (for example, manager approval) and blocks launch until a decision is recorded.
    • On approval, a appLaunch authorization event is emitted and the app launches in the Secure Sandbox runtime.
    • On rejection or timeout, launch remains denied.
  • Use authorization.approval.operations[] for future in-app operations that should also be gated by workflows (for example, appOperation.crm.exportSensitiveData).

See Also ​

Visibility ​

Visibility controls UI presence only.

  • visibility: "visible" — the app appears in the Applications tab.
  • visibility: "hidden" — the app is not shown in the Applications but may still be used via file associations (e.g., Open With, default handlers) when referenced by file association rules.

Target-Based Visibility (Sites) ​

In addition to the visibility field, apps can be constrained to specific user-selected target sites (infrastructure or region) via visibilityConstraints.siteRefs. When Sites are enabled and the user selects a site, only apps whose siteRefs include that site (or have no site constraint) are visible.

See: Sites

Hidden example (used only by file associations):

json
{
  "id": "ms-word",
  "displayName": "Microsoft Word",
  "enabled": true,
  "priority": 200,
  "visibility": "hidden",
  "matchAll": [
    { "type": "targetPath", "pattern": ".*WINWORD\\.EXE$", "patternType": "regex" }
  ],
  "action": "allow"
}

Related

If an app includes configurationTemplates (e.g., apps[].configurationTemplates: ["template-id"]), user configurations derived from those templates will appear in the app’s context menu. Authorization still applies: the app must be discoverable and allowed by at least one enabled action: "allow" policy. Template validation enforces enterprise constraints on user inputs. See: Configuration Templates

Policy Priority ​

When multiple enabled allow policies match the same executable, higher priority values take precedence for tie-breaks in modifications and launch profile merges. If priorities tie, the stable alphabetical ordering of policy id is used.

  • Authorization: any matching allow policy authorizes the launch.
  • Visibility: the final visibility shown in Applications is determined by the effective outcome after tie-breaks (higher priority wins; ties by id).

Hidden Applications and File Associations ​

Policies with visibility: "hidden" are still eligible as handlers via fileAssociations:

  • Hidden apps can appear in Open With lists if the association entry sets showInOpenWith: true.
  • Default handlers will be selected even if the app is hidden, provided security gating passes (the referenced app policy must be enabled and match).

Example (hidden apps referenced by centralized file associations):

json
{
  "fileTypes": [
    {
      "id": "word-docs",
      "displayName": "Word Documents",
      "match": { "extensions": ["doc", "docx"] }
    }
  ],
  "apps": [
    {
      "id": "ms-word",
      "displayName": "Microsoft Word",
      "enabled": true,
      "priority": 200,
      "visibility": "hidden",
      "matchAll": [
        { "type": "targetPath", "pattern": ".*WINWORD\\.EXE$", "patternType": "regex" }
      ],
      "action": "allow",
      "capabilities": [
        {
          "fileTypeRef": "word-docs",
          "verbs": { "open": { "arguments": "\"%1\"" } }
        }
      ]
    }
  ],
  "fileAssociations": [
    {
      "id": "word-docs-routing",
      "displayName": "Word docs",
      "enabled": true,
      "priority": 300,
      "fileTypeRef": "word-docs",
      "actions": [
        { "verb": "open", "displayName": "Open", "appRef": "ms-word", "default": true, "showInOpenWith": true }
      ]
    }
  ]
}

Discovery Scope Reminder ​

Authorization and visibility apply only to executables reachable via Windows shortcuts discovered in:

  • Start Menu (All Users and Current User; recursive)
  • Desktop (Current User; top-level only)

Executables without shortcuts in scope are not discoverable or launchable. Create a shortcut, then author a policy that matches it (for example, via targetPath).

Scope

For end-to-end guidance on what is and is not governed by Launcher policy, see: Limitations & Scope.

Next Steps ​

Turbo.net © 2025