Enterprise Business Portals with IBM Tivoli Access Manager

14 Enterprise Business Portals with IBM Tivoli Access Manager

Other issues

There are a number of other issues that should be kept in mind when deploying

the Web Portal Manager:

򐂰 There is no limit to the number of Web Portal Manager instances that may be

deployed.

򐂰 It is possible to provide access to the Web Portal Manager via a WebSEAL

junction (discussed below); however, transparent sign-on is not supported in

the current (3.9) release. In other words, a user logged on to WebSEAL must

also log on to the Web Portal Manager.

1.2 Blades

Blades are components that provide Access Manager authorization support for

specific application types.

1.2.1 WebSEAL

WebSEAL is a high-performance, multi-threaded reverse proxy, front-ending

back-end Web services that applies a security policy to a protected object space

(which is defined in the authorization database, described in 1.1.3, “Authorization

database” on page 7). WebSEAL can provide single sign-on solutions and

incorporate back-end Web application server resources into its security policy.

Being implemented on an HTTP server foundation, it listens to the typical HTTP-

and HTTPS ports.

More details on an architectural discussion on positioning Access Manager

components, especially WebSEAL, within an Internet-centric environment can be

found in Chapter 2, “Access Manager Web-based architecture” on page 33.

Platforms

WebSEAL is supported on all Access Manager platforms except Intel-based

Linux systems.

Junctions

The back-end services to which WebSEAL can proxy are defined via junctions,

which define a set of one or more back-end Web servers that are associated with

a particular URL.

Chapter 1. Introduction to Access Manager components 15

For example, suppose a junction on the WebSEAL host www.abc.com is defined

such that a request for any URL specifying the path /content/xyz (relative to the

Web space root, of course) is to be proxied to the back-end Web server

def.internal.abc.com. /content/xyz is the

junction point, which can be thought of

in a loose sense as being similar in concept to a file system mount point.

A user at a browser then makes a request for

http://www.abc.com/content/xyz/myhtmlfiles/test.html; WebSEAL will examine

the URL and determine whether the request falls within the Web space for the

/content/xyz junction point. It will then proxy the request to def.internal.abc.com

and forward the resulting response back to the browser.

From the perspective of the browser, the request is processed by www.abc.com.

The fact that it is actually handled by the target server def.internal.abc.com is not

known to the user. To support this, WebSEAL performs various transformations

on the response sent to the browser to assure that the back-end server names

are not exposed. This exemplifies one of the powerful capabilities provided by

WebSEAL junctions, that is, the “virtualization of the Web space.” Junctions may

be defined to the individual Web spaces on various back-end servers, yet from

the browser’s point of view, there is only one single Web space.

It was hinted above that more than one target server may be defined for a

particular junction point. For example, the server ghi.internal.abc.com could be

defined as an additional target for the /content/xyz junction point. In this case,

WebSEAL can load-balance among the servers, and should a back-end server

be unavailable, WebSEAL can continue forwarding requests to the remaining

servers for the junction. For situations where it is important that subsequent

requests for a particular user continue going to the same back-end server,

WebSEAL is capable of supporting this via what are called

stateful junctions.

The above assumes that processing a request does not involve any security

considerations. While WebSEAL is capable of doing a fine job of simply

managing access to Web-based content and applications via simple junctions,

this, of course, leaves out a primary purpose of utilizing WebSEAL. Its integration

with the base Access Manager services to provide access control and flexible

authentication services for Web resources is its main reason for existence.

WebSEAL security functions

One of WebSEAL’s key functions is to protect access to Web content and

applications. To do this, it uses Access Manager’s Authorization Services. The

Authorization Service must know which Web objects (that is, URLs) require

protection, and what level(s) of access to these objects is permitted for the

Access Manager users and groups defined in the user registry.