Skip to main content

Delegation Model

Summary

Keymate's delegation model enables users to transfer a defined subset of their authority to another user, allowing the delegate to act on behalf of the delegator within explicit boundaries. The platform tracks delegation relationships and enforces them through authorization policies that verify delegation context. Delegation supports scenarios such as temporary coverage (a manager delegates approval authority during absence), supervised access (a senior delegates restricted access to a junior), and administrative delegation (an administrator delegates management rights for a department).

Why It Exists

In real organizations, work does not stop when a decision-maker is unavailable. Approvals queue, time-sensitive operations block, and workflows stall. Delegation addresses this by enabling a structured transfer of authority that preserves accountability. The delegator defines what the delegate can do, the platform enforces these limits, and audit trails record every action taken under delegation. This is different from shared credentials or role sharing — delegation is an explicit, auditable, revocable relationship.

Where It Fits in Keymate

The delegation model operates within the authorization model. Delegation roles build on the role hierarchy described in Users, Groups, Roles & Organizations. The scoped administration model governs which administrators can create delegation relationships. The policy evaluation engine evaluates delegation context during policy evaluation, checking whether the acting user holds a valid delegation from the authority holder.

Boundaries

This page covers the delegation authorization model — how delegation relationships work and how policies enforce them. It does not cover:

How It Works

Delegation Relationships

A delegation creates a directional relationship between two users:

  • Delegator — the user who holds the original authority and grants a subset of it
  • Delegate — the user who receives the delegated authority and can act within its limits

Each delegation specifies:

  • The scope of delegated authority (which roles, permissions, or operations transfer)
  • The validity period (start and end dates for the delegation)
  • Constraints on the delegation (which resources, departments, or contexts the delegate can access)
  • Whether the delegate can further sub-delegate (chain delegation)

Delegation Context in Authorization

When a delegate acts under a delegation, the platform includes delegation context in the authorization evaluation:

  1. The delegate's session or token carries delegation metadata (delegator identity, delegation scope)
  2. The policy evaluation engine reads the delegation context alongside the standard evaluation context
  3. Policies that recognize delegation check whether the delegate holds a valid delegation for the requested operation
  4. The platform verifies that the delegation is within its validity period and constraints
  5. If the delegation is valid, the policy evaluates the delegate's action against the delegator's authority

Impersonation and Acting on Behalf

The platform supports a specific form of delegation where the delegate acts as if they were the delegator. In this mode:

  • The delegate's session reflects the delegator's organizational context and roles
  • Actions taken by the delegate appear in audit logs with both the delegate's identity and the delegator's identity
  • The delegate's own roles and attributes are not used — the delegator's authority applies

This mode requires explicit configuration and elevated delegation roles. The platform constrains impersonation to prevent privilege escalation — a delegate cannot impersonate a user with higher authority than the delegator.

Delegation Lifecycle

Delegations follow a managed lifecycle:

  1. Creation — the delegator (or an authorized administrator) creates the delegation with defined scope and validity
  2. Activation — the delegation becomes effective at its start date
  3. Enforcement — the platform evaluates delegation context for every request from the delegate
  4. Revocation — the delegator or an administrator can revoke the delegation before its end date
  5. Expiration — the delegation automatically expires at its end date

Revoked and expired delegations no longer authorize delegate actions. The platform enforces this at evaluation time.

Constraints and Guardrails

The platform enforces several constraints on delegation:

  • Authority ceiling — a delegate cannot receive authority that exceeds the delegator's own authority. If the delegator loses a role, delegations that included that role become ineffective.
  • Scope limits — delegations specify which operations, resources, or departments the delegate can access. The delegate cannot act outside these limits.
  • Chain delegation limits — administrators configure whether delegates can further delegate their received authority. When chain delegation is disabled, authority transfers only one level.

Diagram

Example Scenario

Scenario

A department manager delegates approval authority to a team lead during a two-week absence. The team lead attempts to approve a purchase request, which requires the "approver" role that the manager holds.

Input

  • Actor: Team lead acting under delegation from the department manager
  • Resource: Purchase approval workflow
  • Action: Approve a purchase request
  • Context: Active delegation with "approver" role scope, valid for two weeks. The team lead's own roles do not include "approver."

Expected Outcome

  • Applied — The platform recognizes the active delegation, verifies that "approver" authority falls within the delegation scope, confirms the delegation is within its validity period, and grants the approval action. The audit log records the action with both the team lead's identity (delegate) and the manager's identity (delegator).
  • Why: The delegation model transfers the "approver" authority from the manager to the team lead within defined time bounds. The policy evaluation includes delegation context, allowing the team lead to exercise the delegated authority.

Common Misunderstandings

  • "Delegation gives the delegate all of the delegator's permissions" — No. Delegation specifies a scope — the subset of authority that transfers. The delegator controls which roles, operations, or resources the delegate receives.

  • "Delegation persists after the delegator's authority changes" — No. If the delegator loses a role that the delegation includes, the delegate loses that authority too. The platform evaluates delegation against the delegator's current authority.

  • "Impersonation hides the delegate's identity" — No. Even in impersonation mode, audit logs record both the delegate's identity and the delegator's identity. The platform preserves full accountability for every action.

warning

Enable chain delegation cautiously. When a delegate can sub-delegate, authority can spread beyond the original delegator's intent. Limit chain delegation depth and require explicit approval for sub-delegation.

Design Notes / Best Practices

  • Use time-bounded delegations for temporary coverage (vacations, leaves). Automatic expiration prevents stale delegations from accumulating.
  • Define delegation scopes as narrowly as possible. Delegate only the specific authority needed — not the delegator's full role set.
  • Monitor delegation audit logs for unexpected patterns. Frequent or broad delegations may indicate a process gap that a structural role change would better address.
tip

Create delegation templates for common scenarios (manager absence, audit coverage, project handover). Templates standardize delegation scope and reduce the risk of over-delegation.

  • Delegating approval authority during manager absence
  • Enabling supervised access for junior staff under senior oversight
  • Temporary project-based authority transfer across departments
  • Impersonation for administrative support with full audit trail