Skip to content

Identity & Access Management (IAM)

IAM secures the Open Innovation Platform by regulating user access to system resources. Integrating with OI-IDP (Keycloak-based) for authentication, IAM ensures only authorized users can access, create, or modify data as permitted by their roles.

1. User Management

The IAM module manages users, roles, and groups:

  • Users – Have specific roles that define permitted actions.
  • Roles – Contain sets of permissions or restrictions.
  • Groups – Organize users by role or responsibility for easier bulk management. Groups can have multiple roles, and users can belong to multiple groups.

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.

Example: Assign the “read” permission on a resource to a certain role, so any user with that role can only read (not update) that resource.

2. Authentication with OI-IDP (Keycloak)

Open Innovation IDP (OI-IDP) is an external identity provider that handles:

  • Single-Sign-On (SSO) – Users log in once to access multiple apps.
  • Various Protocols – OIDC, SAML, LDAP integration.

The OI-IDP instance is not directly visible to the end-user, as it is managed behind the scenes by the Open Innovation platform. When a user logs in, OI-IDP issues an access token, which IAM uses to confirm their identity and determine their allowed actions.

3. Authorization Levels

3.1 Resource-Based Access

Resource-based rules govern permissions on distinct resources (e.g., entities, APIs, pages). Each role’s rights define what actions are allowed or restricted on that resource.

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)

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)

Example: 

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

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

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

  • Users with role SME can read/update wells, create/read/update strings, but NOT create reservoirs.

3.2 Data-Based Access

Data-based rules specify who can view or alter specific records.

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.

Each object has authorization fields:

  • _owner_id – The user who created it.
  • _owner_permissions – Actions the owner can perform (read, update, delete, etc.).
  • _roles – Roles allowed to access the object.
  • _role_permissions – Actions those roles can perform.
  • _other_permissions – Actions all other authenticated users can do (e.g., read-only).

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 (Well entity):

{
    "_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,
}

In this example, the owner can read/update/delete, members of SME can read/update, while others can only read.

Time Series Entities (e.g., “production”) rely on their parent entity’s permissions. They do not hold separate authorization attributes. Example:

{
    "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,
}

Next Steps