Grants, not network ACLs
Authorization in Wardengate is session-scoped. A grant binds an identity (or group) to a target asset, optional account mapping, allowed protocols, and optional time window. Network firewalls may still exist, but the meaningful decision happens at the gateway: without a valid grant, the connection never starts.
Five dimensions of a grant
Subject — the user, service account, or vendor identity from your IdP. Target — the host, database, cluster, or application endpoint. Account — the local or federated account used on the target (often injected, never shown). Protocol — SSH, RDP, SQL, or Kubernetes exec. Window — standing entitlement, JIT elevation, or scheduled maintenance slot. All five must align at connect time.
Group inheritance and overrides
Grants attach to IdP groups for scale — SRE, DBA, vendor-support — with optional per-user exceptions. Break-glass grants carry shorter TTLs, mandatory approvers, and enhanced recording. Deny rules take precedence: a explicit block on a target or command surface wins over broader allow policies.
Evaluation at connect time
When an operator initiates a session, the policy engine loads the grant, verifies MFA freshness and device posture, checks approval status for JIT requests, and resolves secrets from your vault integration. The decision is logged with policy version and approver identity — producing evidence that auditors can reconcile without inferring intent from syslog.