webMethods Enterprise Server Security By Andreas Amundin

---

Encryption

Encryption of any data that is exchanged with a broker whether from adapters, brokers, or tools is possible once the enterprise server has been configured with a digital certificate. Data encryption is often not necessary when the integration system recides in a protected Intranet. However, this determination must be done deliberately with awareness of the risks involved.

---

Digital Certificates and Certificate Files

webMethods uses X.509v3 standard digital certificates.

webMethods provides the awcert command line utility to create certificate requests and certificate files as well as installing digital certificates into certificate files. For details about the use of the awcert utility, please refer to Chapter 10 of the AdminAnalysis.pdf document provided with the webMethods Online documentation.

The webMethods Enteprise Server security implementation uses the concept of Trusted Roots to create and validate digital certificates. A Trusted Root is the certificate of the Certification Authority (CA). The CA is responsible for creating and signing certificates. The trusted root digital certificate is needed by the awcert tool to create both certificate requests and certificate files.

One of the most important components to understand for implementing webMethods Enteprise Server security is the certificate file. A certificate file is not a digital certificate. It is a repository for digital certificates and private keys (Figure 1). Because it contains sensitive information the certificate file is password protected.

Adapters and tools must be configured to have access to the certificate file. At the point of configuration the user will be prompted to enter the password for the certificate file. For tools this will occur whenever the tool is started. For adapters this will occur when the adapter is first configured/installed.

---

Security Architecture

At this point we understand the difference between authentication, authorization, and encryption and we know about certificate files and how to create them. To implement security all we have to do is create a bunch of certificate files and configure the enterprise server, adapters, and tools to use them. It is really not that easy.

A simplistic and simple approach to security would be to create one certificate file for the enterprise server and one certificate file for all the clients. The client certificate file is then used for all the adapters and given to all the developers to use with their tools. The security of this system would be compromised for two reasons. First, the password for the client certificate file would most likely become commonly known. Secondly, the enterprise server has to be configured to give full access to any client presenting the client digital certificate.

Another simplistic approach would be to create a different certificate file for each adapter and for each person accessing the system. Systems with many adapters, developers, administrators, and business people (who wants to see the blue balls fly around in the Monitor tool) would become very complex and difficult to manage.

Just like any other aspect of system architecture, security can not be implemented simplistically without dealing with consequences down the road. The security architecture I have used in the past and that I will describe is based on a two fold approach separating component-based security from role-based security.

---

Component Based Security

I use the name component-based security because I have always used a component-based architecture to prevent an integration project from becoming a big ball of mud system. Figure 2 shows the different levels of components that can be defined for an integration system in a component-based approach.

• System is the entire integration system
• Sub-Systems are high-level components that typically represents a resource that is being integrated in the system. Sub-systems are completely independent from any other sub-systems, with the exception of the virtual sub-system defined by the Canonical/UDM events.
• Agents/Adapters are processes that can be distributes across machines on a network.
• Blueprints/Workunits/Integration Components/Configured Operations are controlled by Agents/Adapters and define specific logic.

---

<<Prev  1  [2]  3  Next>>

Go Deeper on the Subject: The wMUsers Discussion Forums