Identity and Access Management Overview

Updated March 09, 2023 03:56

1. Introduction

ZEDEDA Identity and Access Management (IAM) service enable you to manage access to ZedControl services and resources securely. Using IAM, you can create and manage roles and users and use permissions and scopes to deny their access to controller resources.

Fine-grained access control to ZedControl resources

ZEDEDA IAM enables you to define fine-grain control of API and resources by a layered structure:

role
- Access Scope (e.g., All projects or Project A only)
  - Resource Category (e.g., Edge node)
    - Resource permission (e.g., CreateDelete or Read or CreateReadUpdateDelete)

- - Resource Category (e.g., Edge Application)
    - Resource permission (e.g., CreateDelete or Read or CreateReadUpdateDelete)

user
- Assigned to a role

Integrate with your corporate directory

IAM can be used to grant your employee's applications federated access to the ZedControl service APIs, using your existing identity providers such as Microsoft Active Directory, Okta, or Google G Suite. You can use any identity management solution that supports OAuth2 or SAML 2.0, or feel free to use one of our federation samples (AWS Console SSO or API federation).

2. Roles

ZEDEDA IAM service supports roles that consist of a set of access permissions for each access scope. It is possible for a role to have a different set of access permissions for different access scopes (See Appendix A). It supports 3 types of roles:

2.1. Cluster Role

Cluster role can be defined in the context of cluster enterprise only.

Cluster roles usually have scopes across all enterprises with varied permissions.

Cluster role can be created/deleted/modified by code only (All these details can be specified in the configuration file of the specific microservice).

Cluster role is not accessible in any form to customer enterprises
- Customers can't see Cluster roles in the role list and can't create users with Cluster roles.
- Customers can't create Custom roles with permission set of any Cluster role.

2.2. System Role

The system role can be defined in the context of cluster enterprise only.

System roles have scope for their own enterprise only.

System role can be created/deleted/modified by code only (All these details can be specified in the configuration file of a specific microservice).

System role is accessible to customer enterprises
- Customers can see System roles in the role list and create users with System roles.
- Customers can create Custom roles with a permission set of one of the System roles.

2.3. Custom Role

A custom role can be defined in the context of a single customer enterprise.

Custom roles have scope for their own enterprise only.

The custom role can be created/deleted/modified by User Agents (CLI and UI)

A custom role is accessible to only their own enterprise.
- Customers can see their own Custom roles in the role list and create users with custom roles.
- Customers can't see the custom roles of any other enterprise.

2.4. Permissions

Customers can use IAM to have fine-grain control of API and resources through access permissions. Permissions are granted to IAM entity roles, and by default, these entities start with no permissions. In other words, IAM entities can do nothing in the ZedControl until you grant them your desired permissions.

The role supports any combination of Create, Read, Update, Delete permissions. It allows these permissions to be defined for each of the following resource categories:

2.5. Edge Node Access

Controls access to a resource group, hardware brand and model, edge node, and edge node networking.

Control access to asynchronous operations (aka jobs) related to these resources.

2.6. Edge Application Access

Controls access to edge application, edge application image, datastore, edge storage (aka Volume Instance), and edge application networking (aka Network Instance).

Control access to asynchronous operations (aka jobs) related to these resources.

2.7. User Access

Controls access to user, role, authentication profile.

2.8. Enterprise Access

Controls access to enterprise and realm.

2.9. Scopes

Customers can use IAM to have restricted the access scope of the role. The scope is defined on the enterprise and project level:

Enterprise Scope

This defines the enterprises that a role can operate on. The default scope is the "Own" enterprise. Cluster roles have scopes across multiple enterprises. System and Custom roles have scope restricted to "Own" enterprise only.

Project Scope

This defines the resource groups (aka project) a role can operate on. The default scope is "All" projects of the enterprise. Customers can define Custom roles with one or more enterprise projects as the scope.

3. Users

ZEDEDA IAM supports users defined locally in the ZedControl and users imported into the controller but authenticated through a federated Identity provider. Each user is associated with one role. Each user's access to ZedControl service APIs and resources is defined by the permissions and scopes associated with the user's role.

3.1. Local users

Local users are created by User Agents (CLI, GUI, or ZADMIN) or by the sign-up process.
Local users are assigned one of the System or Custom roles during creation.
Authentication and Authorization of the users take place in the ZedControl.
SysAdmin users can edit user profiles in ZedControl.

3.2. Federated users

Federated users are created implicitly during the sign-in process.
Federated users are assigned one of the System or Custom roles based on the Authentication profile created for the Federated Identity provider or through OAuth2 claims.
Authentication of the users takes place by the Federated Identity provider, and authorization occurs in the ZedControl.
SysAdmin user or self can edit only very few fields in the user profile (e.g.notification preference) in the ZedControl. All other fields have to be edited in the Federated Identity provider platform.