The following diagram illustrates the connectivity between the building blocks in a UIM cloud native environment using an example:

Figure 9-1 Integration Across Building Blocks in UIM Cloud Native Environment

Description of "Figure 9-1 Integration Across Building Blocks in UIM Cloud Native Environment"

Invoking the UIM cloud native Helm chart creates a new UIM instance. In the above illustration, the name of the instance is "quick" and the name of the project is "sr". The instance consists of the WebLogic cluster that has one Admin Server and three Managed Servers and a Kubernetes Cluster Service.

The Cluster Service contains endpoints for both HTTP and T3 traffic. The ingress creation script creates the UIM cloud native Ingress object. The Ingress object has metadata to trigger the Generic ingress controller as a sample. Ingress controller responds by creating new front-ends with the configured "hostnames" for the cluster (quick.sr.uim.org and t3.quick.sr.uim.org in the illustration) and the admin server (admin.quick.sr.uim.org) and links them up to new back-end constructs. Each back-end routes to each member of the Cluster Service (MS1, MS2, and MS3 in the example) or to the Admin Server. The quick.sr.uim.org front-end is linked to the back-end pointing to the HTTP endpoint of each managed server, while the t3.quick.sr.uim.org front-end links to the back-end pointing to the T3 endpoint of each managed server.

The prior installation of Ingress Contoller has already exposed Traefik itself through a selected port number on each worker node.

A UIM instance is exposed outside of the Kubernetes cluster for HTTP access via an Ingress Controller and potentially a Load Balancer.

Because the Ingress Controller port is common to all UIM cloud native instances in the cluster, Ingress Controller must be able to distinguish between the incoming messages headed for different instances. It does this by differentiating on the basis of the "hostname" mentioned in the HTTP messages. This means that a client (User Client B in the illustration) must believe it is talking to the "host" quick.sr.uim.org when it sends HTTP messages to Port on the access IP. This might be the Master node IP, or IP address of one of the worker nodes, depending on your cluster setup. The "DNS Resolver" provides this mapping.

In this mode of communication, there are concerns around resiliency and load distribution. For example, If the DNS Resolver always points to the IP address of Worker Node 1 when asked to resolve quick.sr.uim.org, then that Worker node ends up taking all the inbound traffic for the instance. If the DNS Resolver is configured to respond to any *.sr.uim.org requests with that IP, then that worker node ends up taking all the inbound traffic for all the instances. Since this latter configuration in the DNS Resolver is desired, to minimize per-instance touches, the setup creates a bottleneck on Worker node 1. If Worker node 1 were to fail, the DNS Resolver would have to be updated to point *.sr.uim.org to Worker node 2. This leads to an interruption of access and requires intervention. The recommended pattern to avoid these concerns is for the DNS Resolver to be populated with all the applicable IP addresses as resolution targets (in our example, it would be populated with the IPs of both Worker node 1 and node 2), and have the Resolver return a random selection from that list.

An alternate mode of communication is to introduce a load balancer configured to balance incoming traffic to the Ingress Controller ports on all the worker nodes. The DNS Resolver is still required, and the entry for *.sr.uim.org points to the load balancer. Your load balancer documentation describes how to achieve resiliency and load management. With this setup, a user (User Client A in our example) sends a message to quick.sr.uim.org, which actually resolves to the load balancer - for instance, http://sr.quick.uim.org:8080/Inventory/faces/login.jspx. Here, 8080 is the public port of the load balancer. The load balancer sends this to Ingress Controller, which routes the message, based on the "hostname" targeted by the message to the HTTP channel of the UIM cloud native instance.

By adding the hostname resolution such that admin.quick.sr.uim.org also resolves to the Kubernetes cluster access IP (or Load Balancer IP), User Client B can access the WebLogic console via http://admin.quick.sr.uim.org/console and the credentials specified while setting up the "wlsadmin" secret for this instance.

JMS messages use the T3 protocol. Since Ingress Controllers and Load Balancers do not understand T3 for routing purposes, UIM cloud native requires all incoming JMS traffic to be "T3 over HTTP". Hence, the messages are still HTTP, but contain a T3 message as payload. UIM cloud native requires the clients to target the "t3 hostname" of the instance - t3.quick.sr.uim.org, in the example. This "t3 hostname" should behave identically as the regular "hostname" in terms of the DNS Resolver and the Load Balancer. Traefik however not only identifies the instance this message is meant for (quick.sr) but also that it targets the T3 channel of instance.

The "T3 over HTTP" requirement applies for all inbound JMS messages - whether generated by direct or foreign JMS API calls or generated by SAF. The procedure in SAF QuickStart explains the setup required by the message producer or SAF agent to achieve this encapsulation. If SAF is used, the fact that T3 is riding over HTTP does not affect the semantics of JMS. All the features such as reliable delivery, priority, and TTL, continue to be respected by the system. See "Applying the WebLogic Patch for External Systems" for more information.

A UIM instance can be configured for secure access, which includes exposing the T3 endpoint outside the Kubernetes cluster for HTTPS access. See "Configuring Secure Incoming Access with SSL" for details on enabling SSL.

There can be situations where UIM cloud native needs to be accessed from within the same Kubernetes cluster where it is deployed. For example, in a Service and Network Orchestration (SNO) an upstream application (OSM) and downstream application UIM could be deployed in the same Kubernetes cluster. For such requirements, there is no need for the request to be routed via an Ingress Controller or a load balancer and resolved via a DNS Resolver.

UIM cloud native exposes a T3 channel exclusively for such connections and can be accessed via t3://project-instance-cluster-uimcluster.project.svc.cluster.local:31313.

This saves the various network hops typically involved in routing a request from an external client to UIM cloud native deployed in a Kubernetes cluster. The following diagram illustrates inbound JMS requests within the same Kubernetes cluster using an example. For the example, the URL is t3://sr-quick-cluster-uimcluster.sr.svc.cluster.local:31313.

Figure 9-2 Inbound JMS Integration in a Kubernetes Cluster

Description of "Figure 9-2 Inbound JMS Integration in a Kubernetes Cluster"

If SSL is enabled for domains, communication between the domains within the Kubernetes cluster is not secured because the ingress is not involved. See "Setting Up Secure Communication with SSL" for further details.

No specific action is required to ensure the HTTP messages from UIM cloud native instance reach out of the Kubernetes Cluster.

When a domain inside a Kubernetes cluster sends REST API or Web Service requests over HTTP to a domain that is outside the cluster that is enabled with SSL, then you should set up some required configuration. For instructions, see "Configuring Access to External SSL-Enabled Systems".

JMS messages originating from the UIM cloud native instance such as requests to peer systems always end up on local queues. The UIM cloud native Helm chart allows for the specification of SAF connections to remote systems in order to get these messages to their destinations. Custom Templates can be used to create SAF connections in UIM. This allows for a canonical expression of the SAF connectivity requirements, which are uniquely fulfilled by each project by pointing to the appropriate upstream, downstream, peer systems or emulators, and so on.

When a domain inside a Kubernetes cluster sends JMS messages to a domain that is outside the cluster that is SSL-enabled, then see "Configuring Access to External SSL-Enabled Systems" for instructions on setting up some required configuration.

This section demonstrates how to secure incoming access to UIM cloud native. In the TERMINATE strategy, SSL termination happens at the ingress. The traffic coming in from external clients must use one of the HTTPS endpoints. When SSL terminates at the ingress, it implies that communication within the cluster, such as SAF between the UIM cloud native instances, is not secured.

The UIM cloud native toolkit provides the sample configuration for Traefik ingress. If you use Voyager or other ingress, you can look at the $UIM_CNTK/samples/charts/ingress-per-domain/templates/generic-ingress.yaml file to understand the configuration that is applied.

In order for UIM cloud native to participate successfully in a handshake with an external server for SAF integration, the SSL certificates from the external domain must be made available to the UIM cloud native setup. See "Enabling SSL on an External WebLogic Domain" for details about how you could do this for an on-premise WebLogic domain. If you have an external system that is already configured for SSL and working properly, you can skip this procedure and proceed to "Setting Up UIM Cloud Native for Outgoing Access".

You can add additional certificates to an existing trust while a UIM cloud native instance is up and running.

To add additional certificates to an existing trust:

1. Set up UIM cloud native for outgoing access. See "Configuring Access to External SSL-Enabled Systems" for instructions.
2. Copy the certificates from your remote server and load them into the existing truststore.jks file you had created:

   keytool -importcert -v -alias alias -file /path-to/certificate.cer -keystore /path-to/truststore.jks -storepass password

3. Re-create your Kubernetes secret using the same name as you did previously:

   # manually 
   kubectl create secret generic trust_secret_name -n project --from-file=trust_secret_name.jks=</path-to/truststore.jks> --from-literal=passphrase=password 
   
   # verify 
   kubect1 get secret -n project trust_secret_name -o yaml

4. Upgrade the instance to force WebLogic Operator to re-evaluate:

   $UIM_CNTK/scripts/upgrade-instance.sh -p project -i instance -s $SPEC_PATH 

To debug SSL, do the following:

• Verify Hostname
• Enable SSL logging

Verifying Hostname

When the keystore is generated for the on-premise server, if FQDN is not specified, then you may have to disable hostname verification. This is not secure and should only be done in development environments.

managedServers:
 
  project:
    #JAVA_OPTIONS for all managed servers at project level
    java_options: "-Dweblogic.security.SSL.ignoreHostnameVerification=true"

Enabling SSL Logging

When trying to establish the handshake between servers, it is important to enable SSL specific logging.

managedServers:
 
  project:
    #JAVA_OPTIONS for all managed servers at project level
    java_options: "-Dweblogic.StdoutDebugEnabled=true -Dssl.debug=true -Dweblogic.security.SSL.verbose=true -Dweblogic.debug.DebugSecuritySSL=true -Djavax.net.debug=ssl"

UIM cloud native supports wildcard certificates. You can generate wildCard Certificates with the loadBalancerDomainName value provided in spec files. The default is uim.org.

To use Wild Card certificates:

1. To create a self-signed wild card certificate, run the following command:

   openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout $UIM_CNTK/ssl/wildcardkey.pem -out $UIM_CNTK/ssl/wildcardcert.pem -subj "/CN=*.uim.org" -extensions san -config <(echo '[req]'; echo 'distinguished_name=req';
   echo '[san]';echo 'subjectAltName=@alt_names'; \echo '[alt_names]'; \
   echo 'DNS.1=*.uim.org'; \
   )

2. Change the subDomainNameSeperator value from period (.) to hyphen (-) so that incoming hostnames match the wild card DNS pattern and update the $SPEC_PATH/instance.yaml file as follows:

   #Uncooment and provide the value of subDomainNameSeparator, default is "."
   #Value can be changed as "-" to match wild-card pattern of ssl certificates.
   #Example hostnames for "-" admin-quick-sr.uim.org, quick-sr.uim.org, t3-quick-sr.uim.org
   subDomainNameSeparator: "-"

3. For the above configured settings, use the following hostnames to access UIM application for project:sr, instance:quick and loadBalancerDomainName: uim.org:

   uim-admin hostname: admin-quick-sr.uim.org
   uim hostname:  quick-sr.uim.org
   uim-t3 hostname: t3-quick-sr.uim.org