Configure Users

For certain capabilities the Financial Services Workbench relies also on functions that are available through the OpenShift web console. Therefore, it might also be necessary to set up users in OpenShift despite the common setup of users in an OIDC-compliant Identity Provider (e.g. Keycloak).

Note: The authentication mechanism of deployed solutions is only dependent on OIDC-compliant Identity Provider settings.

Overview

Financial Services Workbench Users

These users are typically involved in the design and development process of a solution. They are mainly configured in the attached Identity and Access Management system (IAM), that also serves as the main OIDC-compliant Identity Provider. For configuring system users, please see IAM User Configuration and the underlying User Role Model.

OpenShift Users

Some capabilities of Financial Services Workbench also require that users, that are involved in the process of developing solutions, also need certain permissions on dedicated OpenShift namespaces. For configurations in the OpenShift cluster please see OpenShift User Configuration.

End Users of Deployed Solutions

These users are able to call the published API operations of a deployed solution. They are mainly configured in the attached Identity and Access Management system (IAM), respectively Keycloak, that also serves as the main OIDC compliant Identity Provider. For configuring users, please see IAM User Configuration.

IAM User Configuration

This configuration is done in the admin area of your IAM provider.

Prerequisites

A user with admin rights for the IAM provider.

Realm Model

A realm manages a set of users, credentials, and roles. A user always belongs to a realm. So realms are isolated from one another. We differentiate between two kinds of realms:

One is needed for the Solution Designer and Solution Hub components
One is needed for each k5-project So if you have three k5-projects in place, you could have configured and use up to four realms. It's also possible to use only one realm for the Solution Designer and Solution Hub components and one for every k5-project. That would be useful if all users should have access to all components and all running solutions within the k5-projects for example.

Create New Users

Open your IAM provider's admin console, e.g. https://identity.apps.openshift-01.example.cloud
Choose a realm
Open Users -> Add user
Required input parameters are
- Username
- Email
- First Name
- Last Name
Save the new user

Note: The email address is necessary for the GitLab/IAM integration to work.

Set User's Initial Password

Open the created user
Go to Credentials
Create initial New Password and confirm it
Activate flag Temporary, so that the user has to change the password with the first login
Press Reset Password

Assign Roles to Users

Go to Role Mappings
Select necessary Available Roles
Press Add selected > to assign the roles (see User Role Model)

OpenShift User Configuration

This configuration is done in the RedHat OpenShift cluster. It enables the users to use the integrated capabilities that are provided by the OpenShift console without restrictions.

Show Pipelines and Pipeline Runs

Within Solution Designer, the user is provided with some links to directly access the shown artifact in the OpenShift web console. These links will only work, if the user can log in to the OpenShift web console and has the necessary permissions on the OpenShift cluster. To show pipelines and the pipeline runs including the logs, it is required that a user has the following permission set:

rules: 
  - verbs: 
      - get 
      - list 
      - watch 
    apiGroups: 
      - tekton.dev 
    resources: 
      - tasks 
      - taskruns 
      - pipelines 
      - pipelineruns 
      - pipelineresources 
      - conditions

The permissions only need to be granted to users in those projects, that are stuffed with a k5-project and where solutions will get deployed.

Show Topology, Pods and Logs

In order to view the application composition using the Topology view, a user needs at least the following permission set:

rules:
  - verbs:
      - get
      - list
      - watch
    apiGroups:
      - ''
    resources:
      - pods
      - pods/log
      - pods/status
      - replicationcontrollers
      - services
  - verbs:
      - get
      - list
      - watch
    apiGroups:
      - apps.openshift.io
    resources:
      - deploymentconfigs
  - verbs:
      - get
      - list
      - watch
    apiGroups:
      - apps
    resources:
      - deployments
      - daemonsets
      - replicasets
      - statefulsets
  - verbs:
      - get
      - list
      - watch
    apiGroups:
      - route.openshift.io
    resources:
      - routes
  - verbs:
      - get
      - list
      - watch
    apiGroups:
      - build.openshift.io
    resources:
      - buildconfigs
      - builds

The permissions only need to be granted to users in those projects, that are stuffed with a k5project and where solutions will get deployed.

Example Configuration / Recommendation

Note: We recommend to group users in groups. Instead of defining extra roles for topology view and/or pipeline artifacts, one can also use the predefined cluster-role view.

oc adm policy add-user-to-role view username

Tip: Permissions can be granted cluster-wide or on a per project basis. For security reasons, we recommend to grant only the least minimal necessary permission set to users.

User Role Model

List of roles and their permissions


Name	Description
dc_user	Minimum permissions to access Solution Designer and its local marketplace, as well as for creating a solution.
dc_developer	Acts as a CLI user and source code developer inside Solution Designer. Will be able to pull and push code to a solution related repository.
dc_analyst	Acts as a user inside Solution Designer. Will be able to access Solution Designer's workspace and synchronize this with the related source inside the solution repository.
dc_admin	Acts as an admin user for Solution Designer. Has the permissions to read and delete solutions from Solution Designer. In addition, this role maintains the Git repositories and the pipelines.
mp_user	Can publish solutions to the local marketplace.
mp_manager	Can delete solution templates from the local marketplace.
cm_admin	Acts as an admin user for the configuration management. A user with this role has the permission to use all APIs in the configuration management. Users without this role cannot view or alter any values of the configuration management entries.

Attention: In case a user with dc_admin privileges deletes a solution within Solution Designer without having the permissions in the connected Git repository , the related Git project has to be deleted manually at the remote Git provider.