The next sections will describe the four middleware security technologies individually, how they implement the security functionalities for client/server systems, and how they address the requirements specific to object-based systems. To unify this discus- sion, we treat every technology described as an instance of the same scheme. No mat- ter if it is .NET or Java, COM+ or CORBA, each middleware technology reduces to this one scheme, shown in Figure 7.3, which we put together to help you understand the general concepts.
N OT E
Because applications written for COM and COM+ have a lot in common, we will refer to COM and/or COM+ v1.0 as COM(+) when we do not need to distinguish between the two.In the list below, we explain the levels of the middleware stack as depicted in Figure 7.3:
Client application. Makes RPC-like calls to the server. Because of the abstraction
provided by the proxy of the server object, the client application does not have to be aware of any layers below the proxy.2
Server application. Receives RPC calls, serves them, and returns replies.
Application server. The runtime environment that provides important services
to the critical high-performance and high-scale business applications. Its pres- ence in the stack distinguishes CORBA component model (CCM) from plain CORBA, COM+ from COM, and J2EE from Java 2 Platform, Standard Edition (J2SE). If you have ever tried to implement a business application using plain COM, Java, or CORBA, you are familiar with how much you need to do to man- age the object life cycle, engage in distributed transactions, and implement load balancing and fault tolerance. The application server layer handles those func- tions in CCM, COM+, and J2EE. Due to its complexity, the layer is often tightly integrated with the ORB and object adapters (defined below) and therefore comes bundled with them.
Proxy. A local implementation of the remote server object on the client. It isolates the application from all the details and complexities of the RPC implementation by realizing syntactically the same interface as the object on the target. A proxy marshals requests to and unmarshals responses from the server, and could per- form some other housekeeping work. A client must have a proxy for each inter- face it uses on the server. Proxies are usually compiled out of the interface descriptions. These are interface definition language (IDL) files in COM(+) and
Security of Infrastructures for Web Services 161
2Technically, the application code has to perform some steps to initialize the middleware layer:
via CoInitialize call and its friends in COM(+), and ORB.init() in CORBA. We omit such details to keep the discussion at the higher abstraction layer for now.
CORBA, WSDL files in Web Services, files with Java interfaces extending EJBOb- ject in J2EE, and “remoted” class files in .NET.
Skeleton. The server’s counterpart of the proxy. Also created from the interface
definition, a skeleton performs marshaling/unmarshaling of the call parameters and return values, and hides specifics of the particular ORB implementation.
Object adapter. Sits on top of the object request broker (ORB) and accepts
requests on behalf of the server’s objects. It provides the runtime environment for instantiating server objects, passing requests to them, and assigning the object IDs, called object references. The object adapter also registers object imple- mentations with the ORB and, sometimes, with the implementation repository, so that the server objects can be discovered at run time. Not all middleware technologies (for example, COM(+)) distinguish object adapters from their ORBs, although the adapters are still there.
Object request broker (ORB). Constitutes the core of the middleware layer and
implements most of the plumbing, including composition of the messages given to the network layer for sending, determining where to send messages based on the object reference, establishing virtual (session) channels with other ORBs, and dispatching requests to the server objects. An ORB could be implemented just as a library (like most CORBA ORBs), or could be a set of system services (as in COM+). It cooperates with various services, such as naming, fault tolerance, transactions, and load balancing, to make the life of clients and servers easier. In this discussion, we concentrate on the security service.
Security service. Often tightly integrated with the ORB, the service intercepts the
client’s and server’s interactions to enforce various security policies. Some of them, such as access control, have request granularity and therefore are enforced by request security interceptors. Other policies, such as integrity and confidential- ity protection, are commonly enforced by message security interceptors.
Security mechanism implementation. An implementation of generic network
security technology such as Kerberos, NTLM, SSL, or IPSEC. By and large real- ized as a set of libraries, a security mechanism implementation generates session keys and performs authentication, encryption/decryption, data signing, and validation.
OS and network layers. Perform their usual roles of transmitting the actual mes-
sages between client and server.
Figure 7.3 is an adequate abstraction of the middleware security, although it is not always completely accurate. For example, it shows all the elements in one elegant stack, whereas this is not the case in real situations; the ORB, security service, and secu- rity mechanism layers have a more complex interaction topology, and most elements in the figure interact with the OS. Some applications, due to their security require- ments, could also call the ORB security service and even the security mechanism directly. Nonetheless, keep this figure in mind when you read about the implementa- tion of client and server security services and the secure channels connecting them.
The client and server security services and mechanisms, in cooperation with their ORBs, are the basis for three abstractions very useful for reasoning about distributed systems’ security: client security service, secure channel, and target security service. We will explain them next.
Figure 7.3 Security stack of middleware-based distributed applications.