Ingresses

Ingresses enable a secure entry mechanism for client applications to connect to webMethods Integration with validation and controlled entry points.

In modern application environments, projects often integrate with multiple third-party client applications to deliver business value. An ingress is a mechanism for controlling how external requests enter a system. Ingresses provide secure entry points for service calls and data exchanges that third-party client applications initiate.

Ingress example in webMethods Integration

To better understand ingresses in the context of webMethods Integration, consider a common integration scenario that involves a client application and a SaaS system.

In this scenario, a user wants to synchronize customer data from a CRM system to a cloud-based ERP system that uses a deploy anywhere flow service that is configured in webMethods Integration.

The following high-level steps describe the ingress behavior.

  1. An external system (source system) initiates a runtime service

    When a new customer record is created, the source CRM system sends a request to a deploy anywhere flow service deployed on a runtime. This request represents an inbound call to the platform.

  2. The request enters through the runtime (ingress)

    The request is received by webMethods Integration through the runtime where the flow service is deployed. In the user interface, this runtime and its associated ingress are visible under Ingresses.

  3. The platform applies ingress controls

    Upon receipt, ingress-level controls such as authentication, validation, and monitoring are applied. These controls determine whether the request meets the criteria for further processing.

  4. The service runs and processes data

    After successful ingress validation, the service is run. The service processes the customer data and routes it to the target ERP system by using configured connectors or services.

  5. The runtime sends a response to the source system (optional)

    Based on the service implementation, the runtime sends a success or failure response to the source system.

The mapping of the example to ingress concepts is as follows.

  • The CRM event or service invocation represents an incoming external request to the platform.
  • The deploy anywhere flow service endpoint serves as the ingress entry point for the request.
  • Authentication and validation are applied as ingress controls to make sure that the request meets the processing requirements.
  • Service execution indicates that ingress processing is successfully completed.
  • The customer data payload represents the asset that entered the system through the ingress.

Ingresses key capabilities

  • Token isolation - Each client application receives a unique access token. This option prevents a single point of failure. If one token is compromised, other integrations remain unaffected. This separation helps reduce the impact during a security issue, avoids affecting all integrations, and removes the need for resetting the entire system.
  • Independent access control - Configure access for each client application separately. Applications can access the endpoints and assets that are explicitly granted to them. This restriction minimizes over-permissions and supports the principle of least privilege.
  • Granular permissions - Grant access to only specific project assets for different client applications and manage them independently. This reduces risk and simplifies maintenance.
  • Centralized management - Administrators can view all active integrations and their associated permissions in one place. This transparency helps identify misconfiguration or unauthorized access quickly.
  • Visibility of access permissions - A clear overview is provided within the project, showing which client applications have access to which assets. This visibility enhances transparency and simplifies auditing.
  • Auditability - Track which applications have access to which assets.

Client applications and ingresses

A client application is an external application that sends requests to access services or assets that are exposed through an ingress. Client applications are registered and authenticate with unique credentials or tokens that control their access to services through the defined entry points.

  • An example of a client application is a mobile commerce application that sends requests to an OrderProcessing service through an ingress. The client application uses an access token to start the service endpoint to help ensure that the designated runtime processes only authorized requests.
  • An example of a grouping of ingresses is a client application that is named Customer Operations groups multiple ingresses related to customer-facing functions:
    • An ingress for a Customer Profile integration service from Project A.
    • An ingress for a Customer Orders integration service from Project B.
    • An ingress for a Customer Notifications service from Project C.

Although the ingresses belong to different projects, they are all managed under the same application within the environment. This grouping allows centralized visibility and management of all customer ingress points. Thus, the client application acts as a logical container to manage all related ingress endpoints together.

The relation between an environment, client application, ingress, asset, and runtime is as follows.

  • An environment can have multiple client applications (one-to-many).
  • A client application can have multiple ingresses across projects in an environment (one-to-many).
  • An ingress maps to a single asset within a project (one-to-one).
  • An asset can be mapped to multiple runtimes (one-to-many).

Ingress invocation scenarios and behavior

Security standards require client applications to verify that the server’s certificate is issued by a trusted certificate authority (CA).
Using default certificates for ingress invocation
By default, a public certificate is automatically generated during environment provisioning and is applied to all runtimes. The default certificate can be found under Settings > Key/Certificates > Runtimes. IBM signs this public certificate. To establish trust, the IBM CA certificate must be downloaded from the default security store and added to the calling application’s trust chain. If this step is skipped, the TLS handshake fails and the connection is rejected. While some clients allow disabling server certificate validation, doing so is discouraged.
Using custom certificates for ingress invocation

IBM signs the default certificates, and any client application that does not recognize the IBM certificate authority fails the TLS handshake and does not establish the connection.

Instead of the default certificates, custom certificates can be used. These certificates can be configured globally to all runtimes or selectively to specific runtimes. Custom certificates must be added to a security store before they can be applied.

For more information, see Adding new stores and Setting up custom stores as default stores.

Supported roles for ingress

Project-level permissions determine access to ingress.

Ingress availability

Ingress is supported for deploy anywhere environments only.

Key considerations for ingresses

  • Each ingress can be linked to two types of assets, deploy anywhere flow services and flow services from custom packages.
  • All ingresses are restricted to use the HTTPS protocol and operate over default port 443, ensuring secure communication.
  • Each application supports only basic authentication, requiring users to enter a username and password for accessing ingress. For example, a third-party client application must authenticate by using the credentials that are configured in the runtime environment to access a service.
  • After any modification to the client application or ingress, you must sync and restart the runtime for the changes to take effect.