Security for the webMethods Integration Server By Phillip Leary

---

Overview of Integration Server security

As with any product potentially exposed to external connection, the webMethods Integration Server employs a number of methods to protect itself from unauthorized and unintentional access.

These methods can be grouped into four core areas of security:

• connection
• encryption
• authentication
• authorization

As always with the application of security, it is the responsibility of the server administrators and the service developers to ensure each of these areas are applied in the appropriate manner.

The four core areas mentioned are best explained in order of their use when the Integration Server handles an incoming request.

Connection control is the first level of security imposed, followed by encryption, authentication, and authorization.

Connection control restricts connections to the server based upon host addresses and/or connection port. Following connection control. the server then employs SSL encryption (if requested by the client and supported by the server).

Encryption is not required, but provides a convenient mechanism for protecting the contents of data passed to and from the server. Whether encryption is used or not, the server must then authenticate the connecting user. This requires the user to present valid credentials, in the form of either a digital certificate or a user ID and password.

Once authenticated, the user's credentials are then used to ensure they have the appropriate authorization to execute the requested service.

If you're bored already and just want to get to the example, skip to the section entitled Example Scenario. For more details on each of the areas listed above, read the sections entitled Connection Control, Encryption, Authentication, and Authorization.

---

Connection Control

As mentioned above, connection control restricts connections to the Integration Server based upon the incoming host address and on the port the request comes in on. This security option is configured when the listening port is defined and enabled by the Administrator.

When adding a new listening port (or modifying the default HTTP listening port), the Administrator has two security configuration options available:

• IP Access
• Access Mode

IP Access security allows the Administrator to deny or allow connections based upon the host address of the requesting client. If the Administrator has configured IP Access to Deny by Default, all inbound host addresses will be rejected except those addresses listed in the Allow List.

If the Administrator has configured IP Access to Allow By Default, all inbound host addresses will be allowed except those listed in the Deny List. The Allow and Deny lists are fully configurable and allow for either specific host names, such as not.allowed.com, or ranges, such as *.disallow.net.

IP Access connection security is the first thing checked by the Integration Server when receiving an inbound request.

Access Mode works a bit differently, but is configured in the same way.

Administrators can configure the Access Mode to either Deny By Default, which denies all service requests on this port except those services listed in the Allow List, or configured to Allow By Default, which allows all service requests on this port except those services listed in the Deny List.

The Allow and Deny lists are configured by the Administrator, who may add or remove services to meet their needs.

In this way, listening ports can be configured to allow or reject an inbound request based upon the service requested. Access Mode connection security is the second thing checked by the Integration Server if the inbound host has passed the IP Access check.

Connection level security is configured by the server Administrator. No Developer activities are required.

---

Encryption

Encryption describes support for the Secure Socket Layer standard in communications between the Integration Server and an inbound requestor.

There is nothing mysterious to the configuration of encryption - if the requirements for adding an HTTPS port have been met and the HTTPS port has been added, encryption support occurs automatically for inbound requests on that port.

In order to add an HTTPS port, the Administrator must have at least a private key file, a signed public key certificate file, and the signing Certificate Authority's certificate file. These three files must be placed in a location available to the the Integration Server.

The Administrator may configure the location of these files through either the web-based administration console's Certificates link, which intructs the server to use these files by default for all secure ports, or the Administrator may configure the location of certificate files when adding a new secure port, allowing different HTTPS ports to support different certificate configurations.

Provided the inbound request has passed the connection level security, and the inbound request is through the configured HTTPS port, the Integration Server will then automatically enable encryption support for the communication.

Encryption security is configured by the server Administrator. No Developer activities are required.

---

Authentication

Authentication requires the users of a webMethods system to present valid credentials and provides for both basic authentication (user ID and password) and digital certificate (certificate match) authentication. This means all connecting users or hosts must log in to the Integration Server in some way, whether via interactive or automated connection.

For interactive logons, such as through the administration console, the Developer GUI, or the Web Manager console, the user may use basic authentication and provide a user ID and password for logon.

Provided the user ID is enabled on the Integration Server and the password is correct, the request will be granted and the user ID is passed to the next level of security.

For non-interactive logons, such as automated connections to the Integration Server, the connecting host may present a digital certificate for authentication.

This digital certificate is the public key certificate of the connecting host. The Integration Server will take this public key certificate and compare it to a local copy of the same file. For this to work, of course, a copy of the certificate must already exist locally, and its location configured through the Administrator's Certificate > Client Certificate links.

At the time of configuration, the Administrator specifies the location of the local copy, and very important to remember, maps the certificate to an Integration Server user ID.

If the connecting host presents a valid digital certificate, and the certificate matches the local copy, the request will be granted and the mapped user ID is passed on to the next level of security.

Authentication security is configured by the server Administrator. No Developer activities are required.

---

[1]  2  3  Next>>

Go Deeper on the Subject: The wMUsers Discussion Forums