IBM BAMOE v9 - OIDC secured process management
Architectural Blueprint for a Security Layer to Protect a BPM Application in IBM BAMOE v9 with Kogito/Quarkus Microservices
Business Process Management (BPM) applications have become critical for enterprises to automate workflows and ensure operational efficiency.
IBM Business Automation Manager Open Edition (BAMOE) v9, paired with Kogito microservices, offers a modern, cloud-native approach to BPM.
However, deploying such applications in dynamic environments necessitates a robust security architecture.
This article outlines an architectural blueprint for securing a BPM application running on IBM BAMOE v9.1.1. with Kogito microservices.
Security scenario
Kogito BPM and its APIs for interactions with human processes and tasks adopt an extremely permissive model as of the date of publication of this article, that is, they are based on the concept of self-declaration of the requester.
In technical terms, the APIs for interaction with human tasks accept a pair of parameters with which the requester declares the user-id and the list of roles to which the user is associated.
The architectural choice of the Kogito process and task management framework to externalize the security issue is not questioned and can be justified by the fact that in a cloud-native world, the implementations of security systems are multiple and based on various technologies that are not always interoperable; this means that the security layer for authentication and authorization is delegated externally and consequently each application solution will have to implement its own strategies and implementations.
OIDC is an authentication layer on top of the OAuth 2.0 authorization framework. It allows computing clients to verify the identity of an end user based on the authentication performed by an authorization server, as well as to obtain the basic profile information about the end user in an interoperable and REST-like manner. In technical terms, OpenID Connect specifies a RESTful HTTP API, using JSON as a data format.
1. Overview of the Environment used for this demo
IBM BAMOE v9 with Kogito, a cloud-native toolkit for business automation. The environment typically consists of:
- **Process Engine**: Executes BPMN workflows.
- **Decision Services**: Provides rule-based decision-making (DMN).
- **Kogito/Quarkus Microservices**: Modular microservices for specific business logic.
- **Runtime Environment**: Apps run locally in DEV mode.
The BPM applications processes sensitive data and integrates with external systems, necessitating multi-layered security.
2. Security Layer Architecture
2.1 Layered Security Model
The proposed security architecture adopts a defense-in-depth strategy with the following layers:
1. **Perimeter Security**: Protects external access points.
2. **Application Security**: Ensures secure APIs and services.
2.2 Components of the Security Layer**
2.2.1 API Frontend
This layer acts as a single entry point for all interactions with the BPM application.
- **Authentication & Authorization**: Leverage OpenID Connect (OIDC) JWT token to secure endpoints.
- **Dialect adaptor**: Integrate downstream APIs (process runtime) to propagate credential as from requested by backend service signature.
- **Request Validation**: Verify JWT token against your security policies.
2.2.2 Identity and Access Management (IAM)
Integrate with an enterprise IAM system to enforce user and service authentication.
- **SSO**: Use Keycloak for single sign-on.
- **Role-Based Access Control (RBAC)**: Define granular roles and permissions for accessing BPM and Kogito services.
2.2.3 Service key Mangling/Encryption
Ensure frontend-to-backend protection based on custom service keys.
- **Custom Service Key**: Use custom headers for secure communication between frontend and backend microservices.
2.2.4 Network Policies
Enforce communication boundaries between microservices and external systems.
- Force the communication from frontend to backend on a specific network (127.0.0.1 for the demo).
2.2.4 Architectural schema
In an architectural scenario based on micro-services concepts, the choice made for the security blueprint is to be as less invasive as possible with respect to the BPMN application that is to be created.
To keep the BPMN application as free as possible from external dependencies (other Quarkus extensions and any prerequisites of runtime versions) it was decided to externalize the standard REST transport protection layer on another container, making the most of the security potential applicable to the API and integration with external OIDC systems; in this example a Keycloak server will be used with a realm customized specifically for this scenario.
The blueprint defines the presence of two containers running in the same pod (Sidecar pattern).
The communication between the two containers is based on the IP address 127.0.0.1.
The 'backend' container that will contain the BPMN application will not have http ports exposed to the Service but can only be reached by internal calls or by the 'frontend' container via IP 127.0.0.1.
The 'frontend' container exposes custom and protected REST APIs that allow requests to be mediated towards the 'backend' container.
Sidecar Pattern definition (excerpt from "Designing Distributed Systems" Brendan Burns, published by O'Reilly Media, Inc.)
The sidecar pattern is a single-node pattern made up of two containers. The first is the application container (backend). It contains the core logic for the application. Without this container, the application would not exist. In addition to the application container, there is a sidecar container (frontend). The role of the sidecar is to augment and improve the application container, often without the application container’s knowledge. In its simplest form, a sidecar container can be used to add functionality to a container that might otherwise be difficult to improve. Sidecar containers are coscheduled onto the same machine via an atomic container group, such as the pod API object in Kubernetes. In addition to being scheduled on the same machine, the application container and sidecar container share a number of resources, including parts of the filesystem, hostname and network, and many other namespaces.
2.2.5 Process model
This application is a copy of the 'jbpm-compact-architecture-example' example present in the 'bamoe-9.1.1-examples.zip' archive of the IBM BAMOE v9 distribution.
The 'HRInterview' and 'ITInterview' tasks have been adapted with the configuration of the user roles authorized to interact with these human-tasks.
3. Source code repository
This article is accompanied by a repository in which you will find two applications based on Quarkus; the first called 'backend' creates a BPM application implemented on BAMOE 9.1.1 (technical preview), the second called 'frontend' creates the security protection layer and is integrated with Keycloak for the generation of JWT tokens.
In the supporting description you will find the instructions to run the applications, start processes and complete human tasks.
4. Conclusion
Implementing a security layer for a BPM application on IBM BAMOE v9 with Kogito microservices involves adopting a layered approach.
By integrating IAM, securing APIs, enforcing network policies, enterprises can protect their workflows against modern security threats.
This blueprint provides a foundation to build a robust and secure BPM environment while maintaining agility and performance.
For enterprises seeking enhanced automation, ensuring security is not optional but mandatory for sustained success in a rapidly evolving digital landscape.
References