Access Requests Done Right

Temporary access is one of the hardest problems in identity management. Someone needs production access for an incident. A contractor needs access to a specific tool for two weeks. An engineer needs elevated permissions for a deployment window.

The typical flow: file a Jira ticket, wait for approval, have an admin manually add the user to a group, set a calendar reminder to remove them, forget about the reminder, and discover six months later that the contractor still has admin access.

JustIAM’s Access Requests solve this with a built-in self-service workflow and automatic expiry.

How It Works

1. Admin Creates a Template

Templates define the workflow: which application and mappings are granted, who can approve, how long access can last, and what happens on approval.

Key template fields:

• Application and mappings — what access is actually granted
• Allowed durations — 30 minutes, 1 hour, 8 hours, 3 days, 1 week — admin controls the options
• Approver groups — which groups can approve (open = anyone, restricted = specific groups)
• Notification policy — all approvers, first_n, random_n, or round_robin
• Escalation — auto-escalate to another group after N minutes without a decision
• Custom fields — add extra inputs (text, dropdown, checkbox) the requester must fill out
• Trigger task — fire a Go script on every status change (for external provisioning)

2. User Requests Access

From the JustIAM portal, users select a template and specify:

• Duration — from the template’s allowed options (e.g., “4 hours”, “1 day”)
• Justification — free-text explanation of why they need access
• Custom fields — any additional information the template requires

One pending request per template is enforced — no duplicate submissions.

3. Approver Reviews

Designated approvers see pending requests in their dashboard. Each request shows the user’s justification, current group memberships, and custom field answers for context. Approvers can:

• Approve — grants access immediately
• Deny — with an optional comment
• Discuss — a per-request chat thread for clarification before deciding

4. Access Granted Automatically

On approval, JustIAM creates a temporary system group (__access_req_<id>) with an expires_at timestamp and adds the requester. The application’s mappings are applied through this group — the user gets the claims and access immediately.

5. Access Revoked Automatically

When the request expires, a background task removes the temporary group entirely. The next token issuance for that user no longer includes the granted claims. No cron job, no calendar reminder, no human action required.

Dual enforcement: Even before the background task runs, token issuance filters out expired groups in real-time. Access is effectively revoked within seconds of expiry, not minutes.

Notification & Escalation

Notification policies control who gets bothered:

If nobody responds within the escalation window, the request is automatically forwarded to an escalation group — ensuring it doesn’t sit unanswered indefinitely.

Trigger Tasks: External Provisioning

Templates can wire a script task that fires on every lifecycle event. This is the bridge between JustIAM access grants and external system provisioning.

Example: When access to “Production Database” is approved, the trigger task calls an AWS API to grant temporary RDS credentials. When it expires, the task revokes them.

Available config keys in the triggered script:

event     := config.Get("trigger_event")     // "approved", "expired", etc.
email     := config.Get("requester_email")
appName   := config.Get("app_name")

Failure modes: ignore (fire-and-forget), retry (with max retries), or block (abort the status change if the task fails — useful for “approved” events where external provisioning must succeed).

Full Audit Trail

Every access request generates a complete audit trail:

• Who requested what, and why
• Who approved or denied it, and when
• When access was granted and when it was revoked
• Custom field answers and discussion thread
• Whether the expiry was automatic or manual

Event Integration

Access request lifecycle events (submitted, approved, denied, expired, revoked, escalated) can trigger Event Actions. Common patterns:

• Slack notification when a request is submitted for review
• Webhook to update an external CMDB when access is granted
• Email to the user when their access is about to expire
• Script to provision access in an external system alongside the JustIAM group membership

Terraform Support

Templates are fully manageable via Terraform:

resource "justiam_access_request_template" "prod_access" {
  name        = "Production environment access"
  description = "Grants production credentials for incident response."
  app_id      = justiam_application.prod_db.id

  mapping_ids        = [justiam_app_mapping.prod_readonly.id]
  allowed_durations  = [60, 240, 480]    # 1h, 4h, 8h
  approver_group_ids = [justiam_group.on_call_leads.id]

  require_justification = true
  auto_approve          = false
  notification_policy   = "random_n"
  notification_count    = 2

  escalation_after_mins = 15
  escalation_group_id   = justiam_group.engineering_managers.id
}

Why Not Just Use a Ticketing System?

Ticketing systems add friction and depend on humans remembering to clean up. JustIAM’s access requests are:

• Integrated — the request, approval, provisioning, and revocation happen in one system
• Automatic — expiry is enforced by the system, not by human memory
• Auditable — every step is logged without manual documentation
• Fast — no context-switching to a separate tool
• Extensible — trigger tasks can provision access in any external system

The goal isn’t to replace ITSM for complex change management. It’s to handle the 90% case — “I need temporary access to X” — without the overhead of a full ticketing workflow.

Access Requests documentation →