This chapter describes areas that will enable an enterprise application hosted in a WebSphere Application Server ND v7 (WAS ND7) environment to interact with possibly other applications, resources, and services available in a corporation infrastructure. An example of such external application would be an application running under Domino. The two main areas are indicated as follows:
- Describe the mechanisms used to enable WAS infrastructure components intercommunication. Moreover:
- Explain an additional way in which the same mechanisms can be used to enable WAS infrastructure components communication with external (IBM products) servers, services, and resources.
- Discuss the techniques that will enable users access to SSO across multiple applications in a corporation.
Furthermore, this chapter also covers the following topics that help to round up securing the enterprise infrastructure architecture:
- At the HTTP server level: external security policy manager
- At the Application Server level: trust association interceptor
The chapter will now introduce this book's definition of enterprise infrastructure centered on services provided by a WebSphere Application Server ND v7 environment.
In this chapter, we define enterprise infrastructure architecture or simply enterprise infrastructure as that collection of technologies used in corporate IT environments that perform a very specific job and take a well-defined role among all of the other infrastructure members with the overall objective to supplement each other's part in carrying out a corporation's mission. (Well, that was quite a mouthful). As is expected, a WAS ND7 environment (be it a full WAS ND7 cell or just an enterprise application) is only a small piece of the whole enterprise infrastructure puzzle. Nevertheless, in order for that WAS ND 7 environment to accomplish its purpose, very likely it will depend on various pieces of information that may be logically scattered across multiple technologies supported by the enterprise infrastructure.
Consider the drawing in the following diagram. It is centered around the Enterprise Application (EA). We can distinguish two areas of an Application Server that will interact with the EA: that related to the EA and its data and that of the EA and the environment administrative and support services.
On the one hand, an EA would probably require external data to carry out its function. For example, patient ID to pull medical history, or employee number in order to process pay roll information, and so on. The container capabilities will help the EA obtain any given data needed; be it from a back-end database or from a back-end process
In the diagram, an EA, represented by the solid gold rectangle labeled Enterprise Application, sits on the Web Container (blue rectangle) and the EJB Container (light green rectangle). In addition, several of the major components that may support that particular EA are also shown. For instance, inside the Web Container the EA could require the services of a Portlet Container (tiny red rectangle); or perhaps if the application were involved in some sort of streaming, it could use the services of the SIP Container (tiny orange rectangle). Therefore, the EA should concentrate on its function and data and let the containers supply the means to obtain and save data as well as the mechanisms (such as Java libraries) needed to process the data.
On the other hand, the second form in which an EA will interact with the Application Server is for administrative and support service purposes. The Application Server architecture provides components to supply specific support services such as user registry in which approved user lists reside. This type of information will be defined by the security domain in place; portrayed in the preceding diagram by the rectangle(gray rectangle). In addition, such information would be enforced by the Application Server security components (maroon rectangles).
Furthermore, any configuration changes to the overall WebSphere environment would be handled by the administration interface (orange rectangle), which would keep a copy of the overall environment configuration locally (small green rectangle). The node agent (small dark teal rectangle) is the runtime component that helps Application server members interact with other runtime entities of the WebSphere environment. For instance, if you were using the file-based built-in federated repository as the user registry of your environment and would make a modification such as adding a new member while monitoring the SystemOut.log file of the node agent, you would see that it would be reported the addition of a user. So the WebSphere security infrastructure would alert members to such changes. Let's do a simple observation exercise.
For this simple exercise the following requirements are assumed to be in place and available:
- At least one of the Application Servers created in previous chapters is available
- The global security is using the built-in file-based federated user registry
- Users and groups still exist as defined in prior chapters
Once you insure that the assumption-requirements are in place, proceed to complete the steps given as follows. In this exercise, the Application Server SecureAppServer01 will be used:
- . Open three terminal sessions to your host.
- . In the first terminal session, change your working directory to the node agent logs directory.
- . Start monitoring the SystemOut.log file.
The tail command given as follows could be used:
tail -f SystemOut.log - . In the second terminal session, change your working directory to the SecureAppServer01 logs directory.
- . Start monitoring the
SystemOut.logfile of the SecureAppServer01 server.As in step 3, the tail command can be used in the same way.
If needed, that is if the deployment manager or the node agent processes are not running, perform steps 6-X, as necessary.
- . Change your working directory to the bin directory of the appropriate profile, Deployment Manager, to start the dmgr process or to the Application Server profile to start the nodeagent process.
- . Use the adequate start script to start the dmgr or nodeagent process.
For the dmgr, use the command:
startManager.sh [ -nowait ]Using the
-nowaitflag will free up your terminal faster in case you also need to start the nodeagent process.For the nodeagent, use the command:
startNode.sh [ -nowait ] - . Return focus to terminals one and two.
- . Using a browser, connect to the Deployment Manager Console.
- . Follow the breadcrumb shown to navigate to the Manage Users screen:
Users and groups | Manage Users
- . Optionally, perform a search for users to see currently defined users.
- . Enter data to create a new user.
- . Click the Create button. For User ID enter the value hassan. Type
Hassanin the First name: field. TypeEmployeein the Last name field. Use the string hassan for password. Then click the Create button. - . If desired, enter a couple of blank lines in terminals one and two.
In order to isolate the log data from the upcoming messages (as they are just a long line per screen), you can press Enter return a couple of times while the tail command is running. If desired, do this on both terminals.
- . Back in the browser, create the User ID
hassan.Return focus to the browser and click the Create button. Immediately observe the output on terminals one and two. You should see almost identical messages on both log files monitors.
The preceding screenshot is the output captured from the nodeagent's SystemOut.log file. The first line displays a notification that a user registry change event has taken place. This notification has been sent by the dmgr process to be broadcast by the administrative/security elements as needed. Furthermore, the nodeagent forwards this event notification to Application Servers members of the node.
The next screenshot is practically identical to the first screenshot. This one shows log messages from the SecureAppServer01 and it displays the portion in which the event related to the creation of a new user in the federated registry is received.
