IAM (Identity & Access Management)

is the security layer that controls who can access your DODIL resources and what they’re allowed to do.

It covers:

• Authentication: proving identity (sign-in).
• Authorization: enforcing permissions (access control).
• Credentials & policies for both humans and machines.

How to navigate this section

Most users come here for one of three things:

1. Invite human users to your organization and manage sign-in.
2. Create service accounts so applications, CI/CD, and servers can call DODIL APIs.
3. Define roles and policies to control access to specific resources.

Use these pages as your starting points:

• Users → manage people, invitations, and login settings: Users
• Service Accounts → create machine credentials used by SDKs and automation: Service Accounts
• Roles & Policies → define permissions and scope access: Roles and Policies

Users vs Service Accounts

Both can access DODIL, but they are designed for different use cases.

Users (humans)

Users represent real people: admins, developers, operators, and analysts.

• Login is interactive (for example: email + password, and optionally 2FA)
• Best for using the Console UI and day-to-day operations
• Permissions are typically assigned via roles

Service accounts (machines)

Service accounts are for software—SDK clients, backend services, pipelines, and automation.

• Authentication is non-interactive using service account ID + secret
• Best for production workloads and CI/CD
• Safer than using personal user credentials for automation
• Permissions should be scoped narrowly using policies (least privilege)

Typical flow

A common onboarding path looks like this:

1. Create a service account for your app.
2. Attach the right role/policy to control what it can access.
3. Configure your SDK or service with the service account credentials.

If you’re just getting started, begin with Service Accounts, then come back to define Roles and Policies as your permissions grow.

• Next: Create a Service Account