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 browsers 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 WebSEALs key functions is to protect access to Web content and
applications. To do this, it uses Access Managers 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.

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.