Skip to main content

Identity and Access Management

Identity and Access Management (IAM) is designed to streamline and secure user access across organizational resources. By deploying advanced policies and technologies, IAM ensures that the right individuals gain the appropriate access to critical resources, safeguarding the digital environment against unauthorized access and potential security breaches.

What's the purpose of an IAM?​

Description of the purpose of an IAM: who can do what on which resources?

Authentication​

To access the platform and manage rights, a user must be authenticated. Authentication ensures that a user is the one he/she pretends to be by presenting the good credentials. This is done through the log in process. Our customers are logged in through Enterprise Customer Portal Authentication. Multi-factor authentication ensure security of the system by preventing spoofing, or usage of compromised credentials.

Authorization​

Authorizations (or permissions) are granted to users according to the usage he/she is intended to use. Some users will administrate (administrators of services, or business users), or use final service (final users). For example, a project manager will be granted with rights to build and manage projects. Some special users will administrate the rights and permissions to grant the rights to the others. These users are IAM administrators, or administrators of rights. They will have the responsibility to manage accounts and permissions to all users. Only the IAM administrators will have access to the Identity and Access Management menu. The IAM will provide to users (administrators of IAM, administrators of services, final users) the permissions to access to resources, through a mechanism of roles and policies described below.

Objects Hierarchy​

Our IAM system is structured in a hierarchical fashion, allowing organized management of access and permissions from a high level down to specific resources. The hierarchy is as follows.

Tenant​

Tenant: A tenant references a logical space where a customer has contracted services with Evolution Platform. Within this tenant, customers will be able to manage their resources.

Folders, Projects, Resources​

  • Folders: Folders are containers within a tenant, used to organize projects. A tenant can have multiple folders. A folder can be used to manage projects in different fashions according to the company organization or activity. For example, in a geographical way, to separate activities, or type of markets, or according to organizational considerations. The folders are very useful to organize the segregation of resources.
  • Project: Represents a specific initiative or workstream within a folder. Projects are linked to concrete activities that involve resources and access rights on these resources.
  • Resources: A resource is a logical item that must be protected by the IAM. A resource must be declared in a project. Each time a specific user or machine needs to access a resource, the IAM is requested, to verify if this account benefits of the good authorization.

Roles, Permissions, Role Assignments and Policies​

Permissions​

The possible actions linked with permission are:

  • create
  • read,
  • update,
  • delete,
  • list.

The permissions available are listed on the screen accessible on the left by the item "Permissions". A permission has a label, a type of permission, and a resource on which it is applicable. Permissions are built in and dedicated to a type of resource.

Roles​

A role is a set of permissions, gathered together to simplify the affectation of these permissions to accounts or group of accounts. Roles are accessible from the menu item "Roles Management". There are some pre existing roles (typed "Built in") that are available. These roles are designed for the administration of the IAM resources (tenant, folder, project, resources). Tenant administrators are able to build custom roles to fit the needs of their projects. To create a new role, click on "Create Role" button. A role has a name (Role label), a description, and a permission set. To choose the permissions, one must click on "associated permission" field, then select in the drop down list the available permissions. The selected permissions are added and displayed just below the field. Example: a Folder Administrator is a role that has the responsibility to administrate folders. The Folder administrator has the following permissions:

  • delete_folder
  • read_folder
  • create_folder
  • create_project
  • list_project

Role Assignments​

To be able to affect roles to users, we need to define role assignments. The role assignments are listing who can do what. For example, if the Folder administrators list is empty, nobody can administrate the created folders of the tenant. Then, we need to define the accounts, among the available accounts of the tenant, that are designed as folder administrators. This link can be done to groups of accounts, or directly to accounts. To assign roles to users, one need to click on the Roles Assignment menu, and click on the "Create Role Assignment" button. A role assignment has a label, a description, and a role (on single role can be assigned by role assignment). For example, I can create the Folder administrators, of the sales department. After choosing the Role, one need to choose the users. This can be done by filling the "Assigned to" table, using the + icon. This open a modal window. In the upper part, it is possible to display the available accounts, check them and push them in the lower part for selection, using the down arrow icon. Then validate by clicking on "Attach Account". The table "Assigned to" is now filled. Finally, it is possible to attach policies to the role assignment just defined and save.

Policies​

To be applicable, a role assignment must be linked to a policy. The policy allows to select the concrete item where a role assignment can be enforced. Thus, when creating a policy, one must select the tree item that is involved by the policy (from domain to leave resource) and select the role assignment.

  • Policies are applicable to one or more Role Assignments.
  • A policy is applicable on instances of resources (on any tree item level).
  • A policy is inherited on sons levels except if another policy prevent it.

Managing Access with IAM​

Understanding Role Assignments​

Role Assignments are critical for managing access in our IAM system. They allow you to assign roles to users or groups, effectively granting them the permissions associated with those roles. Each Role Assignment operates within the context of the hierarchy, meaning you can grant access at the level of partner-domains, domains, tenants, folders, or projects.

Example Scenario: Granting Access to a Project​

Suppose you want to grant a group of users the ability to read and write to resources within a specific project. Here's how you would do it:

  • Identify the Role: Determine if an existing role contains the permissions needed. If not, create a new role with the desired permissions.
  • Create a Role Assignment: Within the specific project, create a Role Assignment that associates the role with the group of users.
  • Apply the Role Assignment: Once created, the Role Assignment grants the group of users the permissions contained in the role, for resources within the project.

Understanding Inheritance in IAM​

In our IAM system, inheritance plays a key role in how permissions are managed and applied. This section will explain what inheritance means in the context of our IAM hierarchy and how it influences access control.

What is Inheritance?​

Inheritance in IAM allows permissions assigned at a higher level in the hierarchy (such as the tenant level) to be automatically applied to lower levels (such as folders, projects, and resources within those tenants). This means that if you assign a role to a user or group at the tenant level, the permissions associated with that role are inherited by all the folders, projects, and resources under that tenant.

  1. How Inheritance Works
    Assignment at Tenant Level: When a policy is assigned to a user or group at the tenant level, it grants them the permissions associated with that role across all entities within that tenant. Automatic Propagation: The permissions are automatically propagated down the hierarchy, meaning the user or group will have the same level of access to folders, projects, and resources under the tenant without the need for additional role bindings at each level.
  2. Benefits of Inheritance
    Simplified Management: Inheritance reduces the need for individual role assignments at each level of the hierarchy, simplifying the management of access rights. Consistency: Ensures a consistent application of permissions across a tenant, reducing the risk of accidentally misconfigured permissions. Flexibility: While inheritance provides a broad application of permissions, the ability to override inherited permissions at lower levels allows for granular access control when needed.
  3. Best Practices for Using Inheritance
    Use with Caution: While inheritance simplifies permission management, ensure that roles assigned at the tenant level do not inadvertently grant excessive permissions. Regular Audits: Perform regular audits of your IAM setup to ensure that inheritance is working as intended and that no unnecessary permissions are being propagated.

Best Practices​

  • Principle of Least Privilege: Always grant the minimum permissions necessary for users to perform their tasks.
  • Regular Reviews: Periodically review Role Assignment and roles to ensure they are still necessary and correctly applied.
  • Clear Naming Conventions: Use clear, descriptive names for roles and Role Assignment to simplify management and understanding. To summarize, IAM service store user rights and provide capabilities to validate user rights. User rights are manage with policies objects that bind projects resources to a Role Assignment. Role Assignment then bind an account or a group of account to a list of roles. And at the end a role is composed of permissions.