Skip to content

Identity and Access Management (IAM)

The Identity and Access Management (IAM) module is a crucial component of Open Innovation Platform security that helps manage and control access to the system's resources. This module ensures that only authorized users have access to the system and that their actions are restricted to the permissions assigned to their role. The IAM module integrates with Open Innovation IDP (OI-IDP), based on Keycloak, an external identity provider, to manage authentication and authorization.

User Management

The IAM module is responsible for managing users, roles, and groups within the platform. Users can have multiple roles, and each role has specific permissions and/or restrictions within the system. Administrators can create, edit, and delete users, and assign roles to users within the IAM module.

By assigning roles to users, administrators can control what actions users can perform within the system. For example, if a user has a role that is assigned the "read" permission on a particular resource, they will only be able to read that resource and not perform any other actions on it.

Groups are a way to organize users into specific categories based on their roles or responsibilities within the system. Groups can have multiple roles, and users can belong to multiple groups. This allows administrators to easily manage access permissions for multiple users at once.

Authentication

Open Innovation IDP (OI-IDP), an external identity provider, is integrated with the IAM module to provide robust authentication services. OI-IDP is based on Keycloak and designed to act as a centralized authentication server, handling authentication for multiple applications and providing a seamless single-sign-on (SSO) experience to the end-users. This helps users to access multiple applications with just one set of credentials, making it convenient and efficient. OI-IDP supports various authentication protocols such as OIDC, SAML, and LDAP and can be easily integrated with other identity providers.

The OI-IDP instance is not directly visible to the end-user, as it is managed behind the scenes by the Open Innovation platform. The platform relies on OI-IDP to manage the user authentication and generate the authentication token that will be received by the IAM module. This token acts as a unique identifier for the user and determines the actions they are authorized to perform within the system. The integration of OI-IDP with the IAM module provides a secure and efficient authentication process that ensures the confidentiality of user data and the proper authorization of actions within the system.

Authorization

The system provides two levels of authorization: Resource-Based Access and Data-Based Access. These two authorization levels work together to provide a comprehensive and secure approach to access control within the system. This helps to ensure that users only have access to the resources and data that they need to perform their tasks and that sensitive information is protected from unauthorized access.

Resource-Based Access

Resource-based access authorization refers to the control of access to specific resources within the system. These resources could be anything from specific entities, pages, or even specific functions within an application. Resource-based access authorization ensures that only users who have been granted access to a specific resource can access it. The level of access granted to a user can vary based on the role they play within the system.

The IAM module manages Resource-Based Access by defining access rights for each role in the system. These rights are linked to a role and specify the action that the role can perform on a resource. The right can be either a permission or a restriction to access a resource. The attributes of a right are:

  • Name: the name of the right
  • Role: the role to which the right is assigned
  • Type: the type of the right, which can be either a permission or a restriction
  • Resource Type: the type of the resource, such as "entity," "api," "page," etc.
  • Resource: the specific resource in question
  • Action: the action that the role is allowed (or not) to perform on the resource, such as create, update, delete, read, or * (all)

Example

Here we define 3 rights (2 permissions and 1 restriction), assigned to the role "SME". Based on these rights, a user that has the role "SME":

  • CAN read and update instances of the entity "well" (right-1)
  • CAN create, read, and update instances of the entity "string" (right-2)
  • CAN NOT create instances of the entity "reservoir" (right-1)
# Here we define 3 rights (2 permissions and 1 restriction), assigned to the role "SME"
# based on these rights, a user that has the role "SME":
# - CAN read and update instances of the entity "well" (right-1)
# - CAN create, read and update instances of the entity "string" (right-2)
# - CAN NOT create instances of the entity "reservoir" (right-1)

right-1:
  - name: perm-1
  - role: SME
  - type: permission
  - resource type: entity
  - resource: well
  - action: read, update

right-2:
  - name: perm-2
  - role: SME
  - type: permission
  - resource type: entity
  - resource: string
  - action: create, read, update

right-3:
  - name: rest-1
  - role: SME
  - type: restriction
  - resource type: entity
  - resource: reservoir
  - action: create

Data-Based Access

The IAM module in the platform also manages data-based access authorization. This type of authorization controls access to specific data within the platform, ensuring that only users who have been granted access to specific data can view, modify, or delete it. This level of authorization is crucial for maintaining the privacy and security of data within the system.

Each object in the platform, whether it belongs to a tabular or file entity, has the following authorization attributes that determine its access:

  • _owner: the ID of the owner of the object
  • _owner_permissions: the list of actions that the owner can perform on the object, such as delete, read, or update
  • _roles: the list of roles that the object is assigned to
  • _role_permissions: the list of actions that members of the roles can perform on the object
  • _other_permissions: the list of actions that other authenticated users can perform on the object

Based on these attributes, the IAM module evaluates each user action on an object and determines if the user is allowed to perform it or not. This ensures that only authorized users can access and modify data within the system.

Access to measurement instances of time series or depth series entities is different from other objects in the platform. These instances don't have their own set of authorization attributes. Instead, access to these measurements is determined by the authorization attributes of their parent, which must be an instance of a tabular entity. This linking ensures that the access to a measurement is determined by the authorization attributes of the parent tabular instance. It's important to note that series entities cannot exist independently and must always have a tabular parent entity.

Example

Here's an example of an instance of the entity "well" (tabular entity):

  • The owner of the object can read, update, and delete
  • The members of the role "SME" can only read

and update this object - Other users (not owner and not members of the role "SME") can only read it

{
    "_owner_id": "ef14d2b9-5bec-422e-9db4-cea32dfbfdb5",
    "_owner_permissions": [
        "read",
        "update",
        "delete"
    ],
    "_roles": ["SME"],
    "_role_permissions": ["read", "update"],
    "_other_permissions": ["read"],
    "_created_at": "2023-02-08T11:52:07.996268",
    "_updated_at": "2023-02-08T11:52:07.996268",
    "id": "77de55d6-6242-44cc-9a19-92a83a5d5cfb",
    "field_id": "lam-west",
    "location": {"coordinates": [52.643909, 22.484209999999997], "type": "Point"},
    "name": "W-B-141A",
    "order": "short-long",
    "status": "FL",
    "string_type": "Single String",
    "tower_id": "lam-b",
    "well_type": "Oil producer",
    "year_of_last_workover": 2018,
    "year_of_spud": 2009,
}

Here's an example of an instance of the entity "production" (time series entity):

  • The "production" entity is a child of the "well" entity.
  • The instance does not have authorization attributes.
  • The access is evaluated based on the authorization attributes of its parent.
{
    "id": "a4d7f801-10fa-4661-b5a4-a718dd848f68"
    "well_id": "77de55d6-6242-44cc-9a19-92a83a5d5cfb"
    "time": "2021-04-05 04:00:00"
    "choke": 20
    "field_bsw": 10
    "press_ds_stream": 406.1
    "temo_ds_stream": 64.4
    "thfp": 420.6
    "chp": 75
    "tap": 200.2
    "bcp": 0
    "theoretical_rate": 818.6
    "comment": "Freq to 42Hz at 04:00hrs"
    "h2s": 0,
}