webMethods Enterprise Server Security By Andreas Amundin

---

Introduction

Configuring security for any project is always a challenge. For an integration project it could be even worse. Luckily webMethods Enterprise server comes with a built-in security framework. It is still not as easy as one, two, three, but it has been thought through and it works. It does require a little bit of up-front thinking for it to be effective. If you don’t address security early on, you will run the risk of leaving security out of your first release or implemented very poorly. We all know what tough time constraints, slipping schedules, or scope creep does to requirements deferred to the end of a project.

I did not want to regurgitate what is already written in the documentation provided by webMethods, so I strongly recommend you read Chapter 10 of the AdminAnalysis.pdf document if you haven’t already. This chapter covers all the nitty gritty details of webMethods Enteprise Server security and will familiarize you with some of the terms.

The goal of this article is to give you a pretty good idea of the security framework provided with webMethods Enterprise server and how to design your security architecture. This article will address the security framework up till version 4.5 of webMethods Enteprise Server. I don’t think anything has changed with the introduction of the new broker (version 5.0) but I honestly don’t know as I have not had the pleasure to work with it yet. I encourage anyone with insights in this area to actively participate in the discussion forum for this article. Heck, write an article about any new features and publish it in a future wMUsers eZine.

---

Security Concepts

The security framework provided with webMethods Enteprise Server (ES) supports authentication, authorization, and encryption. ES authenticates clients that connect to an enterprise server. Authenticated clients are then authorized to access the Enterprise Server, brokers, client groups, or client states according to ACL configurations. Encryption is used for adapter-to-broker and broker-to-broker communication.

Security between adapters and native resources falls outside of the webMethods Enteprise Server environment and each adapter conforms (or not) to the security provided by the native resource.

---

Authentication

Enteprise Server only supports authentication using digital certificates. Password authentication is not supported. The use of digital certificates makes it easy to encrypt the data exchanged between clients and brokers.

webMethods requires any client connecting to the enterprise (broker) server to provide a digital certificate to authenticate its identity. Clients can be any of:

• Resource (intelligent or standard) Adapters
• ATC Agents
• Brokers
• Manager tool
• Document (Event) Tracker
• Document (Event) Type Editor
• Enterprise (Visual) Integrator
• Monitor Tool
• Custom Adapters

---

Authorization

Once authenticated, specific access to the Enterprise Server can be granted to the client. Access can be granted to the following types of entities within the enterprise server:

• Enterprise Server
• Brokers
• Client Groups
• Clients (already created client states)

For each type of entity an access control list (ACL) of distinguished names determines which authenticated clients are authorized to access the entity. A distinguished name is the uniquely identifying information for a digital certificate.

In addition to ACL authorization, Client Groups provide an even finer level of access control. Client Groups are used to configure what events/documents clients can publish and subscribe to. This authorization functionality exists independently from the use of digital certificates, but it is not until digital certificates are used for client authentication that the system is secure. Without client authentication, anyone can run an adapter for any client group and both subscribe to and publish events the client group has been configured with.

---

[1]  2  3  Next>>

Go Deeper on the Subject: The wMUsers Discussion Forums