Skip to main content

Privileges

For an API call to be authorized by MARCO, an identity must have assigned a role with the required privileges on the target resource.

At the same time, the identity must have granted a marpp access to use those privileges on its behalf by accepting the application scope.

Roles​

For a given resource, an identity can have one of the following roles:

Role NameDescription
ADMINThe identity can execute any access on the assigned resource.
MANAGERThe identity has read and update privileges on the assigned resource.
READERThe identity has read privileges on the assigned resource.
USERThe identity can use the assigned wallet and plugin resources.

Role hierarchy​

Resources created in MARCO follow a specific organizational hierarchy. This resource hierarchy also represents how privileges are propagated to children resources.

MARCO provides multiple types of resources. The organization and project resources are the most important for structuring the privileges inheritance. One organization can contain many projects. Moreover, each of these projects can have many resources of any other type.

flowchart TB ORGANIZATION(Organization resoruce) PROJECT(Project resource) RESOURCE(Any other resource) ORGANIZATION --> PROJECT PROJECT --> RESOURCE style ORGANIZATION fill:#d5e8d4,stroke:#82b366,stroke-width:1px style PROJECT fill:#dae8fc,stroke:#6c8ebf,stroke-width:1px

The privileges hierarchy follows the same structure. This means that:

  • An identity with a role on an organization will also have that same role on all projects inside that organization.
  • An identity with a role on a project will also have that same role on any other resources inside that project.
  • An identity with a role on any other resource will only have that role on that single resource.
note

The ADMIN role does not propagate as ADMIN to children resources. Instead, it propagates as MANAGER for every resource and to a combination of MANAGER and USER for wallets and plugins.

Example​

Suppose you grant the following privileges to some users:

ResourceIdentityRole
OrganizationUser 1ADMIN
Marpp CUser 2MANAGER
Project 3User 3READER
Wallet AUser 4USER

And that the organization resources look like this:

flowchart TB ORGANIZATION(Organization) PROJECT1(Project 1) PROJECT2(Project 2) PROJECT3(Project 3) subgraph RESOURCES1 MARPPA(Marpp A) MARPPB(Marpp B) SERVICEACCOUNTA(Service account A) PLUGINA(Plugin A) end subgraph RESOURCES2 MARPPC(Marpp C) WALLETA(Wallet A) end subgraph RESOURCES3 SERVICEACCOUNTB(Service account B) end ORGANIZATION --> PROJECT1 ORGANIZATION --> PROJECT2 ORGANIZATION --> PROJECT3 PROJECT1 --> RESOURCES1 PROJECT2 --> RESOURCES2 PROJECT3 --> RESOURCES3 classDef project fill:#dae8fc,stroke:#6c8ebf,stroke-width:1px; classDef resource fill:#f6f8fa,stroke:#d0d7de,stroke-width:1px,color:transparent style ORGANIZATION fill:#d5e8d4,stroke:#82b366,stroke-width:1px class PROJECT1 project class PROJECT2 project class PROJECT3 project class RESOURCES1 resource class RESOURCES2 resource class RESOURCES3 resource

This configuration will result in MARCO granting access to an identity on each resource in the following way:

ResourceUSER 1USER 2USER 3USER 4
OrganizationADMIN
Project 1MANAGER
Marpp AMANAGER
Marpp BMANAGER
Service account AMANAGER
Plugin AMANAGER + USER
Project 2MANAGER
Marpp CMANAGERMANAGER
Wallet AMANAGER + USERUSER
Project 3MANAGERREADER
Service accountMANAGERREADER

Application scope​

Defines what identity privileges can be used by an application when making API requests in the name of the identity.

A marpp can request the following scopes:

Role NameDescription
FULL_ACCESSAllow the application to execute any action as the identity.

See also​