Managing user roles

After configuring access to your Event Processing instance, you can specify roles for your user to determine their permissions.

Event Processing supports the user role with complete access to the Event Processing UI.

Note: You must assign this role to each user.

Setting up roles for local authorization

Along with configuring the user credentials, you must define user mappings through the secret <custom-resource-name>-ibm-ep-user-roles to define the roles for each local user.

The following example shows a sample user mappings file:

{
  "mappings": [
    {
      "id": "user1",
      "roles": [
        "user"
      ]
    }
  ]
}

Where the id is the username that is specified for the user.

Using OpenShift Container Platform web console

Log in to the OpenShift Container Platform web console using your login credentials.
Expand Workloads in the navigation on the left and click Secrets. This lists the secrets available in this project (namespace).
To edit the secret <custom-resource-name>-ibm-ep-user-roles with your local user credentials, go to Actions and click Edit Secret.

Configure your user credentials. For example:

{
  "mappings": [
    {
      "id": "user1",
      "roles": [
        "user"
      ]
    }
  ]
}

Click Save.

Using the CLI

Create a JSON file called myroles.json that contains the user role mappings for your Event Processing instance, for example:

{
  "mappings": [
    {
      "id": "user1",
      "roles": [
        "user"
      ]
    }
  ]
}

Obtain the Base64-encoded string representing the file content. For example, you can run the following command to obtain the string:
```
cat myroles.json | base64
```

Patch the <custom-resource-name>-ibm-ep-user-roles secret with the local user credentials by running the following command:

kubectl patch secret <custom-resource-name>-ibm-ep-user-roles --type='json' -p='[{"op" : "replace" ,"path" : "/data/user-mapping.json" ,"value" : "<your-base64-value>"}]'

where:

<custom-resource-name> is the name of your Event Processing instance.
<your-base64-value> is the Base64-encoded string returned from the previous command.

for example:

kubectl patch secret quick-start-ep-ibm-ep-user-roles --type='json' -p='[{"op" : "replace" ,"path" : "/data/user-mapping.json" ,"value" : "ewogICJtYXBwaW5ncyI6IFsKICAgIHsKICAgICAgImlkIjogInVzZXIxIiwKICAgICAgInJvbGVzIjogWwogICAgICAgICJ1c2VyIgogICAgICBdCiAgICB9CiAgXQp9Cg=="}]'

Note: Alternatively, edit the secret directly and replace the Base64 value associated with data.user-mapping.json. To edit the secret directly, run the following command:

oc edit secret/<custom-resource-name>-ibm-ep-user-roles -o json

Important: For security reasons, delete the local file you created.

Setting up roles for OIDC-based authorization

You must provide user mappings through the secret <custom-resource-name>-ibm-ep-user-roles to match the user subjects of the OIDC identification provider.

The following example shows a sample user mappings file:

{
  "mappings": [
    {
      "id": "<user_subject_1>",
      "roles": [
        "user"
      ]
    }
  ]
}

For more information about retrieving the user subjects, see managing access section.

Setting up OIDC-based authorization with a custom role identifier

Custom role identifiers can be used as the id in the user mappings JSON stored in the <custom-resource-name>-ibm-eem-user-roles secret.

Continuing from the example in managing access, the following is an example of user mappings:

{
  "mappings": [
    {
      "id": "org-admin",
      "roles": [
        "user"
      ]
    }
  ]
}

Where org-admin is a custom identifier, which is inferred from the OIDC provider token, and used to assign user permissions in Event Processing.