Enterprise Business Portals with IBM Tivoli Access Manager

Chapter 16. Application integration 369

򐂰 Allow only authorized users to access any given Web application, regardless

of the source (entry point).

The idea of segregation for external and internal users creates a baseline

infrastructure for enforcing different access control enforcement points for

those entry channels, because there may be cases where you need to

enforce users to only use one specific channel (that is, internal users should

access the internal application server only).

򐂰 Control access to the application pages based on the user’s group

membership.

This can be accomplished either by application coding (that is, programmatic)

or by using WebSEAL (that is, independent). The ideal approach is to use

WebSEAL, keeping the access control functions transparent and independent

from the application.

򐂰 Allow transaction execution only for particular group members or individual

users.

This requirement is related to the way the application handles transactions

and how many internal back-end systems it needs to check in order to

execute a transaction. This is a more programmatic approach in the sense

that the application needs to combine different business logic to decide

whether a user is authorized for a particular operation, which can be different

for other users. This situation can even go to the limit of only allowing

operation for a user under a very special situation, such as allowing money

transfers only to predefined accounts.

16.5 Implementation architecture

We start from a working environment with Access Manager already configured.

The Access Manager Policy Server is installed in the production network,

WebSEAL machines are part of the external infrastructure, and all incoming

HTTP/HTTPS Web requests are directed to the WebSEAL servers in the DMZ.

The new system architecture also requires some additional component

installation, in particular new WebSEAL servers for internal access control. The

application may require some restructuring for some of the controls, especially to

transfer some of the WebLogic controls (as for roles) to Access Manager.

Although this is done without affecting the application code, it is worth mentioning

that any further control should now rely on Access Manager. Figure 16-2 on

page 370 shows the new system architecture that we use with additional

WebSEAL servers in the internal network, making the intranet path controlled by

370 Enterprise Business Portals with IBM Tivoli Access Manager

WebSEAL as well. The other system components stay exactly the same. The

internal users are not impacted since the transition keeps the same system

resources visible, but now with a secure and unique entry point provided by the

WebSEAL layer.

Figure 16-2 Internal access protection

16.5.1 Single sign-on for WebLogic with WebSEAL

One of the major security concerns has always been the multitude of passwords

and different login mechanisms. Web single sign-on (SSO) is the technical

response to the challenge of implementing some level of trust between Web

application components.

The Web server's trust relationship towards WebSEAL is maintained through the

junction defined between WebSEAL and the Web server. Figure 16-3 on

page 371 shows an example how WebSEAL accomplishes the trust concept by

using junctions.

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)

No tes M ail

Calendar

Directory

Firewall

Firewall

Internal

Application

Server

(BEA WLS)

Internal

Web

Server

(IPlanet)

External

Web

Server

(IPlanet)

Firewall

Acess

Manager

Policy

Server

Security

Policies

Mobile

Devices

Technical

Staff

Back-

Office

Backend

database

(Oracle)

Statement

System

Account

System

CRM

Internal

Web

SEAL

Chapter 16. Application integration 371

These junctions can be configured for different levels of trust:

򐂰 They can use SSL encryption for data transfer between WebSEAL and the

back-end Web servers.

򐂰 When using an SSL junction, WebSEAL automatically verifies the server-side

certificate of the back-end Web server.

򐂰 Both WebSEAL and the back-end Web server can implement mutual

authentication using the SSL junction.

To learn more about the details of configuring junctions, refer to the

IBM Tivoli

Access Manager for e-Business WebSEAL Administration Guide Version 3.9

,

GC23-4682.

Figure 16-3 WebSEAL trust concept

The other essential aspect of trust is the WebLogic target application server's

trust of the requester. This requires WebSEAL to act as a front-end

authentication server while the WebLogic Server applies its own authorization

policy onto the user credentials that WebSEAL passes on. To learn more about

the different configuration options on how to pass on user credentials, refer to

Chapter 5, “Authentication and delegation with Access Manager” on page 97.

In our particular approach, both of the previously mentioned aspects of trust are

maintained. Additionally, all of the advantages of WebSEAL (high availability,

load balancing, state management, scalability, support for multiple identity

mechanisms, and so on) and of products that work with Access Manager apply.

WebSEAL

Internet Browser

Internet

Object/ACL

Database

User

Registry

Access Manager

Policy Server

WebSphere Application Server

Lotus Domino

BEA Weblogic Server

iPlanet Web Server

TRUST