Access Approvals

Approval flows for requesting access to a role

Approvable Relationships

You can require approval to create the following models (many-to-many relationships). For documentation purposes, we refer to these as approvable relationships.

Relationship Description
AuthGroupRole An AuthGroup may require approval to be granted access to an AuthRole.
AuthGroupUser An AuthUser may require approval to be granted access to an AuthGroup.
AuthUserRole An AuthUser may require approval to be granted access to an AuthRole.
SaaSProviderGroup An AuthUser may require approval to be granted access to a SaaSProviderGroup.
SaaSProviderRole An AuthUser may require approval to be granted access to a SaaSProviderRole.
SaaSProviderUser An AuthUser may require approval to create a SaaSProviderUser.

How It Works

Before an approvable relationship is created, an ApprovalFlow is created with ApprovalFlowTransaction child records. The ApprovalFlow is the sequence of users or groups that must approve access. An ApprovalFlowTransaction is the audit log entry of who needs to approve and what date and time they approved or denied the request.

The ApprovalFlow uses template metadata from the ApprovalChain and creates ApprovalFlowTransactions using template metadata from the ApprovalPolicy(s) attached to the ApprovalChain.

Each approvable relationship has a Default Approval Chain with one or more ApprovalPolicy(s).

Additional ApprovalChain(s) can be created for each approvable relationship with different sequences of ApprovalPolicy(s), such as allowing automatic access if an AuthUser is a member of an AuthGroup for pre-authorized groups instead of requiring manager and system owner approval in the Default Approval Chain.

To simplify the architectural complexities of a wide variety of criteria, the ApprovalChain criteria uses AuthGroup exclusively. This allows you to simply check if a user is a member of a specific group and use those ApprovalPolicies if true, otherwise it will proceed to the next ApprovalChain in the sequence until it reaches the catch-all Default Approval Chain that will be used if no other criteria are met.

The sequence of ApprovalChain(s) should be ordered from least to most approvals required. Any automatic access approvals should be first in the sequence, followed by simpler approval chains (ex. manager only), followed by complex approval (ex. manager, security team, system owners, etc), followed by the default catch-all approval chain (for full approval chain or non-standard requests).

An ApprovalPolicy is intended to be generic, whereas ApprovalChain is specific to a least privilege use case. Both ApprovalPolicy and ApprovalChain records are reusable and updates are applied globally for all future ApprovalFlow and ApprovalFlowTransaction records.

  1. [Chain] Automatic access for Site Reliability Engineer job family
    • [Policy] group_member Member of Site Reliability Engineer Job Family
  2. [Chain] Automatic access for IT Systems Engineer job family
    • [Policy] group_member Member of IT Systems Engineer Job Family
  3. [Chain] 48 hour access for Security Incident Response Engineer job family
    • [Policy] group_member 48 Hour Access for Security Incident Response Engineer
  4. [Chain] 14 day access for Security Compliance Engineer job family
    • [Policy] group_member 14 Day Access for Security Compliance Engineer
  5. [Chain] Default Approval Chain
    • [Policy] manager Manager Approval - 180 Day Audit
    • [Policy] specific_group Top-Level Infrastructure Security Approval
    • [Policy]specific_user AWS System Owner Approval

User Experience Access Request Concept Art

Architecture Access Approval Flow

Approval Policies

An ApprovalPolicy is a generic, reusable record that specifies what type of approval is required and what AuthGroup or AuthUser is authorized to approve. It also defines when access should expire and/or be audited/reviewed.

An ApprovalPolicy is the template for one of the ApprovalFlowTransaction(s) in an ApprovalFlow.

An ApprovalPolicy can be attached to any ApprovalChain.

Types of Approval Policies

Type Value Description
none No approval required. User can join automatically.
manager Immediate manager approval required. (ex. Manager)
manager_level_flow Manager step-by-step up to specific level (Ex. Manager > Director > VP)
manager_minimum_level Approval by specific level of manager (ex. VP)
specific_group Approval by member of the group specified in auth_group_id
specific_user Approval by user specified in auth_user_id
group_member User can join the group automatically if they are a member of the group in auth_group_id (ex. specific department)
group_manager User can join the group automatically if they are a manager of the group in auth_group_id (ex. manager of specific department)

Database Model

Name Type Description
id uuid Generated ID
auth_group_id uuid Required for some types (specific_group,group_member,group_manager)
auth_user_id uuid Required for some types (specific_user)
type string (enum) See Types of Approval Policies table
manager_level_integer tinyint Required for some types (manager_level_flow,manager_minimum_level)
name varchar(55)
description text
expires_after_count tinyint
expires_after_period string (enum) minute,hour,day,week,month,quarter,year
audit_after_count tinyint
audit_after_period string (enum) minute,hour,day,week,month,quarter,year
display_order tinyint

Create an Approval Policy

An Approval Policy should be generic when possible and not specific to a approvable relationship to maintain fewer policies with a large number of SaaS Providers. For example, you can create a Manager Approval policy with 180 day review that is generic and can be reused. You should think about Approval Policies based on the functionality and least privilege requirements they serve and not the approvable relationships that they are inteded to be attached to (when possible).

You can specify the type of approval policy and select options from a dropdown menu.

Architecture Access Approvals Creation Form

Approval Chains

An ApprovalChain allows you to require multiple approvals to get access by attaching one ApprovalPolicy for each user or group that needs to approve access. For example, you could require manager approval, security approval, and system owner approval by creating three respective ApprovalPolicy records and attaching them to the ApprovalChain.

An ApprovalChain can be reused for any approvable relationship. You can duplicate an ApprovalChain if you need to customize a previously created ApprovalChain. Any changes to an ApprovalChain are versioned, and you can choose which approvable relationships should use the old and new version of an ApprovalChain. Changes will only affect future ApprovalFlow and ApprovalFlowTransaction(s).

Approval Tiers and Sequences

Each ApprovalChain allows you to create a sequence of approvals so that the first ApprovalPolicy/ApprovalFlowTransaction must be approved before the second ApprovalPolicy/ApprovalFlowTransaction notification is sent to the approver.

  • [Policy] Sequence 1 manager Manager Approval - 180 Day Audit
  • [Policy] Sequence 2 specific_group Top-Level Infrastructure Security Approval
  • [Policy] Sequence 3 specific_user AWS System Owner Approval

You can allow simultaneous approvals by setting the sequence value to the same integer.

  • [Policy] Sequence 1 manager Manager Approval - 180 Day Audit
  • [Policy] Sequence 2 specific_group Top-Level Infrastructure Security Approval
  • [Policy] Sequence 2 specific_user AWS System Owner Approval

You can also use approval tiers that supports multiple ApprovalPolicy/ApprovalFlowTransaction for each tier, and requires a tier to be completed before the next tier begins. This is helpful for obtaining preliminary approvals before additional approvers are notified when there is a complex approval chain.

  • Tier 1 - Manager Approvals
    • [Policy] Sequence 1,2,3 manager_level_flow VP Approval (Manager > Director > VP)
  • Tier 2 - Security and System Owner Approvals (simultaneous)
    • [Policy] Sequence 1 specific_group Top-Level Infrastructure Security Approval
    • [Policy] Sequence 1 specific_user AWS System Owner Approval

Architecture Access Approvals Policy Mapping

Approval Chain Policies Example

Architecture Access Approvals Policy Example

1[
2{
3 "id": "abc123",
4 "approvable_model": "saas_provider_user",
5 "approvable_model_id": "yyy",
6 "auth_group_id": "aaa",
7 "sequence": 1,
8 "description": "Automatic access for Site Reliability Engineer job family",
9 "approvalPolicies": [
10 {
11 "id": "bbb",
12 "auth_group_id": "aaa",
13 "type": "group_member",
14 "name": "Member of Site Reliability Engineer Job Family",
15 "description": "This policy grants automatic approval if their job family is Site Reliability Engineer.",
16 "audit_after_count": "90",
17 "audit_after_period": "day",
18 "display_order": "1",
19 }
20 ]
21},
22{
23 "id": "abc123",
24 "approvable_model": "saas_provider_user",
25 "approvable_model_id": "yyy",
26 "auth_group_id": "aaa",
27 "sequence": 2,
28 "description": "Automatic access for IT Systems Engineer job family",
29 "approvalPolicies": [
30 {
31 "id": "bbb",
32 "auth_group_id": "aaa",
33 "type": "group_member",
34 "name": "Member of IT Systems Engineer Job Family",
35 "description": "This policy grants automatic approval if their job family is IT Systems Engineer.",
36 "audit_after_count": "90",
37 "audit_after_period": "day",
38 "display_order": "1",
39 }
40 ]
41},
42{
43 "id": "def456",
44 "approvable_model": "saas_provider_user",
45 "approvable_model_id": "yyy",
46 "auth_group_id": "ccc",
47 "sequence": 3,
48 "description": "48 hour access for Security Incident Response Engineer job family",
49 "approvalPolicies": [
50 {
51 "id": "fff",
52 "auth_group_id": "eee",
53 "type": "group_member",
54 "name": "48 Hour Access for Security Incident Response Engineer",
55 "description": "This policy grants automatic approval for 48 hours if their job family is Security Incident Response Engineer.",
56 "expire_after_count": "48",
57 "expire_after_period": "hour",
58 "display_order": "1",
59 }
60 ]
61},
62{
63 "id": "ghi678",
64 "approvable_model": "saas_provider_user",
65 "approvable_model_id": "yyy",
66 "auth_group_id": "eee",
67 "sequence": 4,
68 "description": "14 day access for Security Compliance Engineer job family",
69 "approvalPolicies": [
70 {
71 "id": "fff",
72 "auth_group_id": "eee",
73 "type": "group_member",
74 "name": "14 Day Access for Security Compliance Engineer",
75 "description": "This policy grants automatic approval for 14 days if their job family is Security Compliance Engineer.",
76 "expire_after_count": "14",
77 "expire_after_period": "day",
78 "display_order": "1",
79 }
80 ]
81},
82{
83 "id": "ghi678",
84 "approvable_model": "saas_provider_user",
85 "approvable_model_id": "yyy",
86 "auth_group_id": null,
87 "sequence": 5,
88 "description": "Default Approval Chain",
89 "approvalPolicies": [
90 {
91 "id": "fff",
92 "auth_group_id": "eee",
93 "type": "manager",
94 "name": "Manager Approval - 180 Day Audit",
95 "description": "This is a generic policy that requires immediate manager approval and is audited after 180 days.",
96 "audit_after_count": "180",
97 "audit_after_period": "day",
98 "approvalChainApprovalPolicy": {
99 "approval_tier": "1",
100 "approval_sequence": "1"
101 }
102 },
103 {
104 "id": "fff",
105 "auth_group_id": "ggg",
106 "type": "specific_group",
107 "name": "Top-Level Infrastructure Security Approval",
108 "description": "This policy is applied to users that have elevated access to top-level infrastructure.",
109 "audit_after_count": "3",
110 "audit_after_period": "month",
111 "approvalChainApprovalPolicy": {
112 "approval_tier": "2",
113 "approval_sequence": "1"
114 }
115 },
116 {
117 "id": "fff",
118 "auth_user_id": "iii",
119 "type": "specific_user",
120 "name": "AWS System Owner Approval",
121 "description": "This policy is applied to elevated access to AWS to ensure that the system owner provides proper orientation.",
122 "audit_after_count": null,
123 "audit_after_peirod": null,
124 "approvalChainApprovalPolicy": {
125 "approval_tier": "2",
126 "approval_sequence": "1"
127 }
128 }
129 ]
130}
131]