IAM lets you grant granular access to specific Zitcha resources and helps prevent access to other resources. IAM lets you adopt the security principle of least privilege, which states that nobody should have more permissions than they actually need.

How IAM works

With IAM, you manage access control by defining who (user) has what access (role) for which resource (team). For example, plans, ad sets, orders and ads are all resources. The metrics and wallets associated with plans and orders are also resources.

In IAM, permission to access a resource isn't granted directly to the end user. Instead, permissions are grouped into roles, and roles are granted to authenticated users.

Zitcha’s IAM policy defines and enforces what roles are granted to which user within the scope of a team. Each policy is attached to a resource. When an authenticated user attempts to access a resource, IAM checks the resource's policy to determine whether the action is permitted.

A user may belong to one or multiple organisations. A user’s role and team configuration is unique per organisation.

This model for access management has three main parts:

• User: A user is a registered account for an individual. Each user has its own identifier, email address.
• Role: A role is a collection of permission sets. Permissions determine what operations are allowed on a resource. When you grant a role to a user, you grant all the permissions that the role contains.
• Team: A team is a scope of resources. Teams contain scopes which determine which resources a user is allowed access to. A user must occupy a role within each team.

The below documents are a guide to grant, change, and revoke access to users, roles, and teams:

Roles & Permissions

Teams

Users

The below documents provide further information on Zitcha's authentication methods and integrations:

Single Sign On (SSO)

Accessing Zitcha