Enterprise Business Portals with IBM Tivoli Access Manager

Chapter 15. Protection of external Web resources 337

15.5 Implementation architecture

Since it is part of the assumption that we start from a working environment, it

seems logical that we need to accommodate some changes to make everything

work properly. We define some basic categories to map the complexity of the

scenario we are working and the changes that are necessary to make the new

scope functional. Ideally, those changes have to be minimum, if none. As the

scenarios become more complex, there may be a need for some special

changes in one or two topics, but not all.

15.5.1 General implementation considerations

We define the following criteria to structure the changes in the solution that we

are implementing in this as well as in the other banking scenarios.

Architecture changes

This is the high-level summary of the changes in the environment as a whole.

Some categories are described in more detail since they have much more

granular steps to be considered.

This section highlights changes with respect to:

򐂰 Application (general components, communication, hardware, redundancy)

򐂰 Network (routes, firewalls)

򐂰 Firewall (rules, logging, approvals)

򐂰 Security (availability, confidentiality, integrity concerns)

Security retrofit

This category describes the security changes that are required in the application

and system level. For applications, this encompasses code changes and new

code. For the system level, this includes agents, protocols, or software

components that are new to the existing solution set. The items and questions

covered are:

򐂰 Application (do we need to redo code?)

򐂰 Existing Web controls and logic (do we need to change/split pages?)

򐂰 In-house authorization engine (can it be used to coexist with legacy systems if

required?)

Network changes

This includes the specific network changes required in the environment other

than the security-specific ones.

338 Enterprise Business Portals with IBM Tivoli Access Manager

The items addressed here are:

򐂰 DMZ re-engineering (do we need to re-model network zones and firewall

machines?)

򐂰 System isolation (DMZ) and direct access to servers (is there any change

necessary to support access to the environment?)

򐂰 Administrative networks (is there any change necessary to the management

network?)

򐂰 VPN access (are there any changes necessary for external users coming

through VPN channels?)

Production

This affects the machines, software, operating system, and personnel that

maintain the environment. The items covered here include:

򐂰 Any new hardware for the Access Manager environment (physical

requirements)

򐂰 Technical support access (is there any technical support restriction?)

򐂰 Production support access (can production support still operate the running

systems? Is there any new component to be monitored on a regular basis?)

15.5.2 Implementation considerations

For our first project, external Web resource protection, we outline the major

components and changes required to the running system. Figure 15-2 on

page 339 shows the new Access Manager components required in our

environment. The external WebSEAL server is the only entry point for external

users. The Access Manager Policy Server is the main component for security

policy administration. The Authorization Server is installed on the same machine.

Although you can optionally install the Access Manager WPM features to

manage most of the Access Manager resources using a graphical user interface

implemented on one of the Web application servers, in our scenario we use the

command line interface pdadmin to execute all the maintenance procedures as

described in the next sections. The following bullets summarize the major

changes in the environment:

򐂰 There are no significant architectural changes for the application in this

phase. Since this is an add-on security implementation, there is little

complexity in modifying application behavior. On the other hand, the overall

system architecture now relies on a security reference monitor as part of the

standard core features that require installation, customization, and

maintenance to some extent.

Chapter 15. Protection of external Web resources 339

򐂰 There are few security retrofit concerns to the existing applications. This

approach is the simplest implementation considering an existing group of

Web applications and thus does not pose severe or complex problems for

configuration. In order to make the application receive the same session

controls as it may be expecting for authentication, the login code should have

some small changes.

򐂰 There are changes on the network level in order to fit the new hardware and

software components. Some network and firewall reconfiguration is required

to allow WebSEAL communication from the Internet DMZ to the Production

Network. This is discussed in more detail in 15.6.3, “Network changes” on

page 358.

Figure 15-2 External protection example

Internet

Browser

External

Networks

External

Web

SEAL

Intranet

Internet

DMZ

Browser

Internal Production Network (core)

LDAP

Directory

(IPlanet)

Middleware

Server

(MQ Integrator)

External

Application

Server

(BEA WLS)

Wireless

Gateway

Clearing

System

Business

Partners

Customers

Temporary

Users

Public

(Guest)

Notes Mail

Calendar

Directo ry

Firewall

Firewall

Internal

Application

Server

(BEA WLS)

Internal

Web

Server

(IPlanet)

External

Web

Server

(IPlanet)

Firewall

Access

Manager

Policy

Server

Security

Policies

Mobile

Devices

Technical

Staff

Back-

Office

Backend

database

(Oracle)

Statement

System

Account

System

CRM