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

Get Enterprise Business Portals with IBM Tivoli Access Manager now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.