DotID Terminology Guide

This document defines every key term in the DotID authorization system, clarifies the relationships between similar concepts, and maps each term to its AWS IAM equivalent.

Quick Guide

DotID Term	AWS Equivalent	One-line Description
Account	AWS Account	Isolated tenant boundary; scopes all IAM resources
Organization	AWS Organizations	Container that groups multiple Accounts under one management Account
Organizational Unit (OU)	AWS OU	Hierarchical folder structure within an Organization for grouping Accounts
IamPolicy	IAM Managed Policy	A reusable JSON policy document (Allow/Deny statements) scoped to an Account
IamInlinePolicy	IAM Inline Policy	A policy document embedded directly on a user or group; not reusable
PolicySet	IAM Identity Center Permission Set	A named bundle of IamPolicy references; assigned to Groups for Account access
AccountAssignment	IAM Identity Center Account Assignment	The (Group + Account + PolicySet) binding that grants access
Group	IAM Identity Center Group	Cross-account group of principals; the "who" in AccountAssignments
IamGroup	IAM Group	Account-scoped group of IAM users; policies attached at group level
ResourcePolicy	Resource-based Policy	Policy attached to a specific resource (FRN); enables cross-account access
ServiceControlPolicy (SCP)	SCP	Org-level policy restricting maximum permissions for OUs/Accounts
PermissionBoundary	Permissions Boundary	Per-user ceiling on effective permissions within an Account
ActionNamespace	Service Namespace	A registered service prefix for policy actions (e.g., devices:)
FRN	ARN	FlexGalaxy Resource Name — globally unique resource identifier

Policy Types in Detail

DotID has five distinct policy types. Understanding when to use each is critical.

IamPolicy (Managed Policy)

API:

/api/v1/accounts/{accountId}/iam-policies

AWS Equivalent:

IAM Managed Policy

A reusable, versioned JSON policy document scoped to an Account. Contains Statement array with Effect, Action/NotAction, and Resource/NotResource fields.

Key characteristics:

• Reusable: Can be attached to multiple users and IAM groups via IamPolicyAttachment

• Versioned: Up to 5 versions retained; supports rollback via set-default

• Account-scoped: Each policy belongs to one Account (identified by accountId)

• Managed policies: Platform-provided policies (isManaged=true) cannot be modified or deleted by tenants

Example:

{
  "Statement": [
    {
      "Sid": "AllowDeviceRead",
      "Effect": "Allow",
      "Action": ["devices:Read", "devices:List"],
      "Resource": ["frn::devices:device/*"]
    }
  ]
}

PolicySet (Permission Set)

API:

/api/v1/permission-sets

AWS Equivalent:

IAM Identity Center Permission Set

A named bundle of IamPolicy references. PolicySets group multiple IamPolicies together so they can be assigned as a unit. They are the "what rules apply" axis of the AccountAssignment binding.

Key characteristics:

• Global scope: PolicySets are not scoped to a specific Account

• References IamPolicies: Contains a list of IamPolicy IDs via many-to-many junction table (permission_set_iam_policies)

• Used in AccountAssignments: The PolicySet is one of three axes in the (Group + Account + PolicySet) binding

• Named for humans: Examples: AdministratorAccess, ReadOnlyAccess, BillingAccess

重要

PolicySet vs IamPolicy: An IamPolicy is a single policy document with Allow/Deny statements. A PolicySet is a collection of IamPolicies bundled together under a name. Think of it as a folder of policies.

IamInlinePolicy

API:

/api/v1/accounts/{accountId}/iam-inline-policies

AWS Equivalent:

IAM Inline Policy

A policy document embedded directly on a specific principal (user or IAM group). Unlike managed policies, inline policies cannot be shared.

Key characteristics:

• One-to-one: Each inline policy belongs to exactly one principal

• Not reusable: Cannot be attached to other principals

• Account-scoped: Belongs to a specific Account

• Use sparingly: Prefer managed policies for reusability

ResourcePolicy

API:

/api/v1/accounts/{accountId}/resource-policies

AWS Equivalent:

Resource-based Policy (e.g., S3 bucket policy)

A policy attached to a specific resource identified by its FRN. Used primarily for cross-account access — the policy specifies which external principals can access the resource.

Key characteristics:

• Attached to resources, not users or groups

• Specifies principals: Uses Principal field to identify who can access

• Cross-account: Primary mechanism for granting access to principals in other Accounts

• Same-account: For same-account principals, a resource policy Allow alone is insufficient — the principal must also have an identity-policy Allow

ServiceControlPolicy (SCP)

API:

/api/v1/organizations/{orgId}/scps

AWS Equivalent:

Service Control Policy

Organization-level policies that set maximum permission boundaries for all Accounts and OUs within the Organization.

Key characteristics:

• Restrictive only: SCPs define what actions are allowed; they cannot grant permissions by themselves

• Inherited: Attached to OUs; child Accounts inherit the restriction

• Org-scoped: Only exist within an Organization context

• Management Account exempt: The management Account is never restricted by SCPs

Identity Center Concepts in Detail

The following three concepts work together to implement DotID's Identity Center (the AWS IAM Identity Center equivalent):

Group

API:

/api/v1/groups

AWS Equivalent:

IAM Identity Center Group

A cross-account group of principals (users or service accounts). Groups are the "who" axis of AccountAssignments. They are not scoped to any specific Account — they exist at the platform level.

注釈

Group vs IamGroup: Group is a platform-level cross-account group used in Identity Center AccountAssignments. IamGroup is an Account-scoped IAM group used for attaching policies within a single Account. They serve different purposes.

AccountAssignment

API:

/api/v1/account-assignments

AWS Equivalent:

IAM Identity Center Account Assignment

The central binding that connects three axes:

1. Group — who is accessing (which principals)

2. Account — where they are accessing (which tenant)

3. PolicySet — what rules apply (which policies)

When a user attempts to access an Account, the PDP:

1. Resolves the user's Group memberships

2. Finds AccountAssignments matching those Groups + the target Account

3. Collects all IamPolicies from the matched PolicySets

4. Evaluates those policies against the requested action and resource

PolicySet (in this context)

See PolicySet (Permission Set) above. In the Identity Center workflow, the PolicySet determines which IamPolicies a Group receives when accessing an Account. A single AccountAssignment references exactly one PolicySet.

Relationship Diagram (Text)

Organization
├── Account (management)
├── Account (member)
│   ├── IamPolicy (managed, versioned)
│   │   └── IamPolicyVersion (history)
│   ├── IamInlinePolicy (per-user/group)
│   ├── IamGroup (account-scoped)
│   │   ├── IamGroupMembership → user
│   │   ├── IamPolicyAttachment → IamPolicy
│   │   └── IamInlinePolicy (group-level)
│   ├── ResourcePolicy (per-resource)
│   ├── PermissionBoundary (per-user)
│   └── AuditEvent (immutable log)
└── ServiceControlPolicy → ScpAttachment → OU/Account

Group (platform-level, cross-account)
├── GroupMember → user/client
└── AccountAssignment
    ├── → Account
    └── → PolicySet
          └── → IamPolicy (many-to-many)

Authorization Pipeline (10-Step PDP)

When a request is evaluated by the PDP:

1. Resource Policy — Check resource-based policies on the target FRN

2. Root User Bypass — Root users of the target Account get implicit Allow

3. Resolve Identity Policies — Gather all applicable IamPolicies from AccountAssignments, IAM groups, inline policies, and policy attachments

4. Explicit Deny — Any Deny statement in identity policies → DENY

5. SCP Check — If in an Organization, verify the action is allowed by SCPs

6. Explicit Allow — Any Allow statement in identity policies → tentative ALLOW

7. Delegated Admin — Check if Account is a delegated admin for the service

8. Permission Boundary — If user has a boundary, verify the action is within it

9. Allow — All checks passed → ALLOW

10. Default Deny — No explicit Allow found → DENY

Account-Scoped vs Global

Entity	Scope	Notes
IamPolicy	Account-scoped	Each belongs to one Account
IamInlinePolicy	Account-scoped	Attached to principal within Account
IamGroup	Account-scoped	IAM group within an Account
ResourcePolicy	Account-scoped	Attached to resource in Account
PermissionBoundary	Account-scoped	Per-user within Account
Group	Global (platform)	Cross-account, used in IDC
PolicySet	Global (platform)	Named bundle of IamPolicies
AccountAssignment	Global (platform)	Binds Group + Account + PolicySet
Organization	Global (platform)	Groups Accounts
ServiceControlPolicy	Organization-scoped	Restricts OUs/Accounts within Org
ActionNamespace	Global (platform)	Registers service action prefixes

User Types

Type	Keycloak Realm	Description
root	flexgalaxy	Platform root users; own Accounts
iam	acc-*	Account-scoped IAM users
ic	idc-*	Identity Center users; access via AccountAssignments

Common Confusion Points

Q: What is the difference between IamPolicy and PolicySet?

An IamPolicy is a single policy document containing Allow/Deny statements (e.g., "allow devices:Read on frn::devices:device/*"). A PolicySet is a named collection of IamPolicies (e.g., "AdministratorAccess" contains 5 different IamPolicies granting full access).

Analogy: IamPolicy is a single page of rules. PolicySet is a binder containing multiple pages.

Q: Why is the API endpoint called ``/permission-sets`` instead of ``/policy-sets``?

Historical naming. The API endpoint remains /permission-sets for backwards compatibility.

Q: What is the difference between Group and IamGroup?

Group is a platform-level cross-account group used in Identity Center AccountAssignments. It spans across Accounts.

IamGroup is an Account-scoped group (like AWS IAM Groups). Policies are attached to IamGroups, and users within the IamGroup inherit those policies — but only within that specific Account.

Q: When does a ResourcePolicy grant access by itself?

Only for cross-account access. If a resource policy Allow matches a principal from a different Account, the access is granted immediately (no identity policy needed). For same-account principals, the resource policy Allow alone is not sufficient — the principal must also have an identity policy Allow.