196 DCE Replacement Strategies
10.1 Scenario description
The scenario in this chapter demonstrates mixed Java and C replacement
strategies for an application that has direct dependencies on secure DCE RPC
services as well as the DCE login, authorization, and PAC services. The
motivation for using this migration scenario might be for an application with a
large amount of existing business logic written in C but with all future
development to be in Java. The chapter is organized as follows:
The first section discusses the initial application with its DCE dependencies
and how these dependencies are removed.
The example application with its DCE dependencies is explained in section
10.2, “DCE application” on page 203.
Section 10.3, “Replacement roadmap” on page 210 explains the steps
necessary to build and run the revised application in the WebSphere
Section 10.4, “Revised application discussion” on page 230 explains and
discusses the revised application.
Section 10.5, “Administration considerations and interfaces” on page 245
contains some considerations for the management of the new environment.
Section 10.6, “Discussion and conclusions” on page 246 concludes the
10.1.1 Initial application with DCE dependencies
The application for this scenario is a simple lookup of employee information that
might be found in an on-line corporate directory. This application uses RPC
security and authorization to restrict the type of information a directory user can
view about an employee.
This scenario uses a highly secure DCE application server and client. The
application server ensures that the network security server has validated its
credentials before starting. The application client validates the identity of the
server before sending it any remote procedure calls (RPCs). When the
application client makes RPCs, it annotates the DCE binding handle with the
current user’s authentication information. The application server verifies that the
RPC was made using packet privacy (encryption) and checks the user’s
authorization based on the membership in suitable groups in accordance with the
The security policy for this sample application is shown in Table 10-1 on
Chapter 10. Scenario 3: Secure RPC application #1 197
Table 10-1 Security policy
Unauthenticated users cannot see any information in the directory. Authenticated
but unauthorized users can see only department information. Directory
application employees or managers can see more information.
Figure 10-1 depicts the scenario application with the DCE dependencies.
Figure 10-1 Application with DCE dependencies
department deny allow allow allow
grade deny deny allow allow
salary deny deny deny allow
DCE Security Server
TGT: Ticket Granting Ticket
PAC: Privilege Attribute Certificate
DCE CDS Server
Appl. Server NodeAppl. Client Node
198 DCE Replacement Strategies
With reference to Figure 10-1 on page 197, the following simplified steps take
1. Upon startup, the application server registers its binding information with the
local DCE host server.
2. The application server registers its binding information with the DCE CDS
3. The application client queries the DCE CDS server for the partial binding
information of the application server.
4. The application client queries the application server node’s DCE host server
for the full binding information.
5. The application client requests and receives the required tickets from the
DCE security server.
6. The application client connects to the application server and forwards the
ticket with the PAC information.
7. The application server performs local authorization decisions.
10.1.2 Revised application without DCE dependencies
The replacement strategies to be demonstrated in this scenario are:
Replacing DCE application client with a CORBA client.
Replacing DCE application server with a WebSphere Application Server
running a stateless session enterprise bean using a JCA connector and JNI to
interface with the C business logic. The reason for this choice is that a
stateless session bean maps most closely to context-free DCE RPC. DCE
RPC using contexts, on the other hand, most likely would be mapped to J2EE
stateful session beans.
Replacing mutual authentication between client and server with the SSL
secure exchange identity certificates.
Replacing DCE authorization with WebSphere J2EE authorization.
Replacing DCE protection with Secure Sockets Layer (SSL).
Preserving the business logic in C language.
Figure 10-2 on page 199 illustrates the revised application in the WebSphere
Application Server environment.