ibm tivoli access manager for e-business: plug-in for ibm ...publib.boulder.ibm.com › tividd ›...
TRANSCRIPT
IBM
Tivoli
Access
Manager
for
e-business
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Version
5.1
SC32-1367-00
���
IBM
Tivoli
Access
Manager
for
e-business
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Version
5.1
SC32-1367-00
���
Note
Before
using
this
information
and
the
product
it
supports,
read
the
information
in
Appendix
D,
“Notices,”
on
page
91.
First
Edition
(November
2003)
This
edition
applies
to
version
5,
release
1,
modification
0
of
IBM
Tivoli
Access
Manager
(product
number
5724-C08)
and
to
all
subsequent
releases
and
modifications
until
otherwise
indicated
in
new
editions.
©
Copyright
International
Business
Machines
Corporation
2001,
2003.
All
rights
reserved.
US
Government
Users
Restricted
Rights
–
Use,
duplication
or
disclosure
restricted
by
GSA
ADP
Schedule
Contract
with
IBM
Corp.
Contents
Preface
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. vii
Who
should
read
this
book
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. vii
What
this
book
contains
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. vii
Publications
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. viii
Release
information
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. viii
Base
information
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. ix
Web
security
information
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. ix
Developer
references
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. x
Technical
supplements
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. x
Related
publications
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. x
Accessing
publications
online
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiii
Accessibility
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiv
Contacting
software
support
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiv
Conventions
used
in
this
book
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiv
Typeface
conventions
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiv
Operating
system
differences
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiv
Chapter
1.
Introducing
the
IBM
Tivoli
Access
Manager
plug-in
for
Edge
Server
.
.
.
.
. 1
System
requirements
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 1
Tivoli
Access
Manager
security
model
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 1
Plug-in
for
Edge
Server
security
enforcement
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 2
Reverse
proxy
access
control
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 3
Forward
proxy
access
control
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 4
Chapter
2.
Installing
the
plug-in
for
Edge
Server
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 7
Supported
platforms
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 7
Disk
and
memory
requirements
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 7
Software
prerequisites
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 8
Installing
the
plug-in
for
Edge
Server
on
AIX
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 8
Installing
the
plug-in
for
Edge
Server
on
Linux
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 8
Installing
the
plug-in
for
Edge
Server
on
Solaris
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 9
Installing
the
plug-in
for
Edge
Server
on
Windows
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 9
Configuring
the
plug-in
for
Edge
Server
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 9
Upgrading
the
plug-in
for
Edge
Server
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 10
Chapter
3.
Administering
the
plug-in
for
Edge
Server
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 11
Managing
user
accounts
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 11
Creating
a
Tivoli
Access
Manager
object
space
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 11
Creating
an
object
space
for
the
caching
proxy
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 12
Creating
an
object
space
for
other
Web
servers
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 12
Starting
and
stopping
the
plug-in
for
Edge
Server
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 13
Configuration
files
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 13
Base
configuration
file
(ibmwesas.conf)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 14
Object
space
definition
configuration
file
(osdef.conf)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 14
User
mapping
configuration
file
(usermap.conf)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 16
Log
files
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 16
Configuring
the
login
method
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 17
Basic
Authentication
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 18
Form
login
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 18
Client
certificates
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 20
Configuring
tag-value
pair
support
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 21
Chapter
4.
Understanding
the
plug-in
for
Edge
Server
configuration
.
.
.
.
.
.
.
.
. 23
Server
configuration
model
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 23
©
Copyright
IBM
Corp.
2001,
2003
iii
Server
configuration
concepts
applied
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 24
Object
space
configuration
model
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 26
Single
signon
configuration
model
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 28
Configuration
procedure
summarized
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 28
Chapter
5.
An
example
plug-in
for
Edge
Server
deployment
.
.
.
.
.
.
.
.
.
.
.
.
. 31
Designing
the
Web
site
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 31
Content
distribution
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 31
Single
signon
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 31
Configuring
the
Web
site
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 32
Chapter
6.
Creating
a
Cross-domain
Authentication
Service
.
.
.
.
.
.
.
.
.
.
.
.
. 35
Authentication
models
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 35
Single
authentication
model
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 35
Dispatched
authentication
model
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 36
Building
a
custom
shared
library
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 38
CDAS
application
development
kit
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 38
Programming
the
custom
shared
library
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 38
User
authentication
data
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 39
Returning
the
client
identity
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 40
Compiling
the
custom
shared
library
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 40
Configuring
the
plug-in
for
Edge
Server
to
use
a
custom
shared
library
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 41
Configuring
a
custom
shared
library
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 41
Custom
shared
library
configuration
scenario
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 41
Configuring
the
demonstration
library
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 42
Loading
the
custom
shared
library
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 43
CDAS
core
and
utility
functions
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 44
CDAS
API
core
function
reference
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 44
xauthn_authenticate
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 45
xauthn_change_password
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 46
xauthn_initialize
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 47
xauthn_shutdown
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 48
Chapter
7.
Cross
domain
single
signon
solutions
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 49
CDSSO
authentication
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 49
Customizing
single
signon
authentication
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 49
CDSSO
features
and
requirements
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 50
Authentication
process
flow
for
CDSSO
with
CDMF
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 50
Configuring
CDSSO
authentication
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 51
e-Community
single
signon
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 55
e-Community
single
signon
features
and
requirements
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 56
e-Community
single
signon
process
flow
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 56
The
e-community
cookie
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 58
The
vouch-for
request
and
reply
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 58
The
vouch-for
token
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 59
Encrypting
the
authentication
token
data
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 59
Enabling
and
disabling
e-community
single
signon
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 60
Configuring
an
e-community
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 61
Configuring
e-community
single
signon
-
an
example
configuration
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 62
Chapter
8.
Removing
the
plug-in
for
Edge
Server
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 65
Removing
the
plug-in
for
Edge
Server
on
AIX
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 65
Removing
the
plug-in
for
Edge
Server
on
Linux
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 66
Removing
the
plug-in
for
Edge
Server
on
Solaris
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 66
Removing
the
plug-in
for
Edge
Server
on
Windows
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 67
Appendix
A.
Base
configuration
file
reference
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 69
Appendix
B.
Object
space
definition
configuration
file
reference
.
.
.
.
.
.
.
.
.
.
. 71
iv
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Server
definitions
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 71
Single
signon
definitions
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 81
Cross
domain
single
signon
definitions
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 83
Appendix
C.
Command
reference
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 85
wesosm
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 86
wslstartwte
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 88
wslstopwte
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 89
Appendix
D.
Notices
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 91
Trademarks
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 93
Glossary
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 95
Index
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 101
Contents
v
vi
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Preface
The
IBM®
Tivoli®Access
Manager
(Tivoli
Access
Manager)
plug-in
for
IBM
WebSphere®
Edge
Server
(plug-in
for
Edge
Server)
provides
authentication
and
authorization
security
services.
Installed
on
the
Edge
Server
caching
proxy,
the
plug-in
for
Edge
Server
is
the
gateway
between
your
clients
and
Web
servers,
implementing
the
security
policies
that
protect
your
Web
resources.
The
plug-in
secures
Web
content
and
application
server
resources
at
the
caching
proxy
through
virtual
hosting,
and
provides
single
signon
solutions
for
the
protected
Web
servers.
IBM®
Tivoli®
Access
Manager
(Tivoli
Access
Manager)
is
the
base
software
that
is
required
to
run
applications
in
the
IBM
Tivoli
Access
Manager
product
suite.
It
enables
the
integration
of
IBM
Tivoli
Access
Manager
applications
that
provide
a
wide
range
of
authorization
and
management
solutions.
Sold
as
an
integrated
solution,
these
products
provide
an
access
control
management
solution
that
centralizes
network
and
application
security
policy
for
e-business
applications.
Note:
IBM
Tivoli
Access
Manager
is
the
new
name
of
the
previously
released
software
entitled
Tivoli
SecureWay®
Policy
Director.
Also,
for
users
familiar
with
the
Tivoli
SecureWay
Policy
Director
software
and
documentation,
the
management
server
is
now
referred
to
as
the
policy
server.
The
IBM
Tivoli
Access
Manager
Plug-in
for
Edge
Server
User’s
Guide
provides
installation
instructions,
administration
procedures,
and
technical
reference
information
for
securing
your
Web
domain
using
the
plug-in
for
Edge
Server.
Who
should
read
this
book
This
guide
is
for
system
administrators
responsible
for
the
installation,
deployment,
and
administration
of
the
plug-in
for
Edge
Server.
Readers
should
be
familiar
with
the
following:
v
Microsoft®
Windows®
and
UNIX®
operating
systems
v
Security
management
v
Internet
protocols,
including
HTTP,
HTTPS,
and
TCP/IP
v
Lightweight
Directory
Access
Protocol
(LDAP)
and
directory
services
v
Authentication
and
authorization
v
Tivoli
Access
Manager
security
model
and
its
capabilities
If
you
are
enabling
Secure
Sockets
Layer
(SSL)
communication,
you
also
should
be
familiar
with
SSL
protocol,
key
exchange
(public
and
private),
digital
signatures,
cryptographic
algorithms,
and
certificate
authorities.
What
this
book
contains
This
book
contains
the
following
sections:
v
Chapter
1,
“Introducing
the
IBM
Tivoli
Access
Manager
plug-in
for
Edge
Server,”
on
page
1
Describes
the
Tivoli
Access
Manager
security
model
and
the
plug-in
for
Edge
Server
security
enforcement.
©
Copyright
IBM
Corp.
2001,
2003
vii
v
Chapter
2,
“Installing
the
plug-in
for
Edge
Server,”
on
page
7
Provides
installation
and
configuration
instructions
for
all
supported
platforms.
v
Chapter
3,
“Administering
the
plug-in
for
Edge
Server,”
on
page
11
Describes
how
to
manage
user
accounts,
create
a
Tivoli
Access
Manager
object
space,
and
start
and
stop
the
plug-in.
Also
describes
the
plug-in
for
Edge
Server
configuration
and
log
files.
v
Chapter
4,
“Understanding
the
plug-in
for
Edge
Server
configuration,”
on
page
23
Provides
an
overview
of
the
plug-in
for
Edge
Server
configuration.
v
Chapter
5,
“An
example
plug-in
for
Edge
Server
deployment,”
on
page
31
Describes
an
example
deployment
of
the
plug-in
for
Edge
Server
in
a
Web
commerce
environment.
v
Chapter
6,
“Creating
a
Cross-domain
Authentication
Service,”
on
page
35
Explains
how
to
create
a
Cross-domain
Authentication
Service
(CDAS)
shared
library,
which
enables
custom
handling
and
processing
of
client
authentication
information.
Also
describes
how
to
configure
the
plug-in
for
Edge
Server
to
recognize
the
specific
type
of
authentication
data
being
passed
to
the
custom
shared
library.
v
Chapter
8,
“Removing
the
plug-in
for
Edge
Server,”
on
page
65
Describes
how
to
unconfigure
and
remove
the
plug-in
for
Edge
Server
from
each
of
the
supported
operating
system
platforms.
v
Appendix
A,
“Base
configuration
file
reference,”
on
page
69
v
Appendix
B,
“Object
space
definition
configuration
file
reference,”
on
page
71
v
Appendix
C,
“Command
reference,”
on
page
85
Publications
Review
the
descriptions
of
the
Tivoli
Access
Manager
library,
the
prerequisite
publications,
and
the
related
publications
to
determine
which
publications
you
might
find
helpful.
After
you
determine
the
publications
you
need,
refer
to
the
instructions
for
accessing
publications
online.
Additional
information
about
the
IBM
Tivoli
Access
Manager
for
e-business
product
itself
can
be
found
at:
http://www.ibm.com/software/tivoli/products/access-mgr-e-bus/
The
Tivoli
Access
Manager
library
is
organized
into
the
following
categories:
v
“Release
information”
v
“Base
information”
on
page
ix
v
“Web
security
information”
on
page
ix
v
“Developer
references”
on
page
x
v
“Technical
supplements”
on
page
x
Release
information
v
IBM
Tivoli
Access
Manager
for
e-business
Read
This
First
(GI11-4155-00)
Provides
information
for
installing
and
getting
started
using
Tivoli
Access
Manager.
v
IBM
Tivoli
Access
Manager
for
e-business
Release
Notes
(GI11-4156-00)
viii
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Provides
late-breaking
information,
such
as
software
limitations,
workarounds,
and
documentation
updates.
Base
information
v
IBM
Tivoli
Access
Manager
Base
Installation
Guide
(SC32-1362-00)
Explains
how
to
install
and
configure
the
Tivoli
Access
Manager
base
software,
including
the
Web
Portal
Manager
interface.
This
book
is
a
subset
of
IBM
Tivoli
Access
Manager
for
e-business
Web
Security
Installation
Guide
and
is
intended
for
use
with
other
Tivoli
Access
Manager
products,
such
as
IBM
Tivoli
Access
Manager
for
Business
Integration
and
IBM
Tivoli
Access
Manager
for
Operating
Systems.
v
IBM
Tivoli
Access
Manager
Base
Administration
Guide
(SC32-1360-00)
Describes
the
concepts
and
procedures
for
using
Tivoli
Access
Manager
services.
Provides
instructions
for
performing
tasks
from
the
Web
Portal
Manager
interface
and
by
using
the
pdadmin
command.
Web
security
information
v
IBM
Tivoli
Access
Manager
for
e-business
Web
Security
Installation
Guide
(SC32-1361-00)
Provides
installation,
configuration,
and
removal
instructions
for
the
Tivoli
Access
Manager
base
software
as
well
as
the
Web
Security
components.
This
book
is
a
superset
of
IBM
Tivoli
Access
Manager
Base
Installation
Guide.
v
IBM
Tivoli
Access
Manager
Upgrade
Guide
(SC32-1369-00)
Explains
how
to
upgrade
from
Tivoli
SecureWay
Policy
Director
Version
3.8
or
previous
versions
of
Tivoli
Access
Manager
to
Tivoli
Access
Manager
Version
5.1.
v
IBM
Tivoli
Access
Manager
for
e-business
WebSEAL
Administration
Guide
(SC32-1359-00)
Provides
background
material,
administrative
procedures,
and
technical
reference
information
for
using
WebSEAL
to
manage
the
resources
of
your
secure
Web
domain.
v
IBM
Tivoli
Access
Manager
for
e-business
IBM
WebSphere
Application
Server
Integration
Guide
(SC32-1368-00)
Provides
installation,
removal,
and
administration
instructions
for
integrating
Tivoli
Access
Manager
with
IBM
WebSphere®
Application
Server.
v
IBM
Tivoli
Access
Manager
for
e-business
IBM
WebSphere
Edge
Server
Integration
Guide
(SC32-1367-00)
Provides
installation,
removal,
and
administration
instructions
for
integrating
Tivoli
Access
Manager
with
the
IBM
WebSphere
Edge
Server
application.
v
IBM
Tivoli
Access
Manager
for
e-business
Plug-in
for
Web
Servers
Integration
Guide
(SC32-1365-00)
Provides
installation
instructions,
administration
procedures,
and
technical
reference
information
for
securing
your
Web
domain
using
the
plug-in
for
Web
servers.
v
IBM
Tivoli
Access
Manager
for
e-business
BEA
WebLogic
Server
Integration
Guide
(SC32-1366-00)
Provides
installation,
removal,
and
administration
instructions
for
integrating
Tivoli
Access
Manager
with
BEA
WebLogic
Server.
v
IBM
Tivoli
Access
Manager
for
e-business
IBM
Tivoli
Identity
Manager
Provisioning
Fast
Start
Guide
(SC32-1364-00)
Preface
ix
Provides
an
overview
of
the
tasks
related
to
integrating
Tivoli
Access
Manager
and
Tivoli
Identity
Manager
and
explains
how
to
use
and
install
the
Provisioning
Fast
Start
collection.
Developer
references
v
IBM
Tivoli
Access
Manager
for
e-business
Authorization
C
API
Developer
Reference
(SC32-1355-00)
Provides
reference
material
that
describes
how
to
use
the
Tivoli
Access
Manager
authorization
C
API
and
the
Tivoli
Access
Manager
service
plug-in
interface
to
add
Tivoli
Access
Manager
security
to
applications.
v
IBM
Tivoli
Access
Manager
for
e-business
Authorization
Java
Classes
Developer
Reference
(SC32-1350-00)
Provides
reference
information
for
using
the
Java™
language
implementation
of
the
authorization
API
to
enable
an
application
to
use
Tivoli
Access
Manager
security.
v
IBM
Tivoli
Access
Manager
for
e-business
Administration
C
API
Developer
Reference
(SC32-1357-00)
Provides
reference
information
about
using
the
administration
API
to
enable
an
application
to
perform
Tivoli
Access
Manager
administration
tasks.
This
document
describes
the
C
implementation
of
the
administration
API.
v
IBM
Tivoli
Access
Manager
for
e-business
Administration
Java
Classes
Developer
Reference
(SC32-1356-00)
Provides
reference
information
for
using
the
Java
language
implementation
of
the
administration
API
to
enable
an
application
to
perform
Tivoli
Access
Manager
administration
tasks.
v
IBM
Tivoli
Access
Manager
for
e-business
Web
Security
Developer
Reference
(SC32-1358-00)
Provides
administration
and
programming
information
for
the
cross-domain
authentication
service
(CDAS),
the
cross-domain
mapping
framework
(CDMF),
and
the
password
strength
module.
Technical
supplements
v
IBM
Tivoli
Access
Manager
for
e-business
Command
Reference
(SC32-1354-00)
Provides
information
about
the
command
line
utilities
and
scripts
provided
with
Tivoli
Access
Manager.
v
IBM
Tivoli
Access
Manager
Error
Message
Reference
(SC32-1353-00)
Provides
explanations
and
recommended
actions
for
the
messages
produced
by
Tivoli
Access
Manager.
v
IBM
Tivoli
Access
Manager
for
e-business
Problem
Determination
Guide
(SC32-1352-00)
Provides
problem
determination
information
for
Tivoli
Access
Manager.
v
IBM
Tivoli
Access
Manager
for
e-business
Performance
Tuning
Guide
(SC32-1351-00)
Provides
performance
tuning
information
for
an
environment
consisting
of
Tivoli
Access
Manager
with
the
IBM
Tivoli
Directory
server
as
the
user
registry.
Related
publications
This
section
lists
publications
related
to
the
Tivoli
Access
Manager
library.
The
Tivoli
Software
Library
provides
a
variety
of
Tivoli
publications
such
as
white
papers,
datasheets,
demonstrations,
redbooks,
and
announcement
letters.
The
Tivoli
x
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Software
Library
is
available
on
the
Web
at:
http://www.ibm.com/software/tivoli/library/
The
Tivoli
Software
Glossary
includes
definitions
for
many
of
the
technical
terms
related
to
Tivoli
software.
The
Tivoli
Software
Glossary
is
available,
in
English
only,
from
the
Glossary
link
on
the
left
side
of
the
Tivoli
Software
Library
Web
page
http://www.ibm.com/software/tivoli/library/
IBM
Global
Security
Kit
Tivoli
Access
Manager
provides
data
encryption
through
the
use
of
the
IBM
Global
Security
Kit
(GSKit)
Version
7.0.
GSKit
is
included
on
the
IBM
Tivoli
Access
Manager
Base
CD
for
your
particular
platform,
as
well
as
on
the
IBM
Tivoli
Access
Manager
Web
Security
CDs,
the
IBM
Tivoli
Access
Manager
Web
Administration
Interfaces
CDs,
and
the
IBM
Tivoli
Access
Manager
Directory
Server
CDs.
The
GSKit
package
provides
the
iKeyman
key
management
utility,
gsk7ikm,
which
is
used
to
create
key
databases,
public-private
key
pairs,
and
certificate
requests.
The
following
document
is
available
on
the
Tivoli
Information
Center
Web
site
in
the
same
section
as
the
IBM
Tivoli
Access
Manager
product
documentation:
v
IBM
Global
Security
Kit
Secure
Sockets
Layer
and
iKeyman
User’s
Guide
(SC32-1363-00)
Provides
information
for
network
or
system
security
administrators
who
plan
to
enable
SSL
communication
in
their
Tivoli
Access
Manager
environment.
IBM
Tivoli
Directory
Server
IBM
Tivoli
Directory
Server,
Version
5.2,
is
included
on
the
IBM
Tivoli
Access
Manager
Directory
Server
CD
for
the
desired
operating
system.
Note:
IBM
Tivoli
Directory
Server
is
the
new
name
for
the
previously
released
software
known
as:
v
IBM
Directory
Server
(Version
4.1
and
Version
5.1)
v
IBM
SecureWay
Directory
Server
(Version
3.2.2)
IBM
Directory
Server
Version
4.1,
IBM
Directory
Server
Version
5.1,
and
IBM
Tivoli
Directory
Server
Version
5.2
are
all
supported
by
IBM
Tivoli
Access
Manager
Version
5.1.
Additional
information
about
IBM
Tivoli
Directory
Server
can
be
found
at:
http://www.ibm.com/software/network/directory/library/
IBM
DB2
Universal
Database
IBM
DB2®
Universal
Database™
Enterprise
Server
Edition,
Version
8.1
is
provided
on
the
IBM
Tivoli
Access
Manager
Directory
Server
CD
and
is
installed
with
the
IBM
Tivoli
Directory
Server
software.
DB2
is
required
when
using
IBM
Tivoli
Directory
Server,
z/OS™,
or
OS/390®
LDAP
servers
as
the
user
registry
for
Tivoli
Access
Manager.
Additional
information
about
DB2
can
be
found
at:
http://www.ibm.com/software/data/db2/
IBM
WebSphere
Application
Server
IBM
WebSphere
Application
Server,
Advanced
Single
Server
Edition
5.0,
is
included
on
the
IBM
Tivoli
Access
Manager
Web
Administration
Interfaces
CD
for
the
desired
operating
system.
WebSphere
Application
Server
enables
the
support
of
Preface
xi
both
the
Web
Portal
Manager
interface,
which
is
used
to
administer
Tivoli
Access
Manager,
and
the
Web
Administration
Tool,
which
is
used
to
administer
IBM
Tivoli
Directory
Server.
IBM
WebSphere
Application
Server
Fix
Pack
2
is
also
required
by
Tivoli
Access
Manager
and
is
provided
on
the
IBM
Tivoli
Access
Manager
WebSphere
Fix
Pack
CD.
Additional
information
about
IBM
WebSphere
Application
Server
can
be
found
at:
http://www.ibm.com/software/webservers/appserv/infocenter.html
IBM
Tivoli
Access
Manager
for
Business
Integration
IBM
Tivoli
Access
Manager
for
Business
Integration,
available
as
a
separately
orderable
product,
provides
a
security
solution
for
IBM
MQSeries®,
Version
5.2,
and
IBM
WebSphere®
MQ
for
Version
5.3
messages.
IBM
Tivoli
Access
Manager
for
Business
Integration
allows
WebSphere
MQSeries
applications
to
send
data
with
privacy
and
integrity
by
using
keys
associated
with
sending
and
receiving
applications.
Like
WebSEAL
and
IBM
Tivoli
Access
Manager
for
Operating
Systems,
IBM
Tivoli
Access
Manager
for
Business
Integration,
is
one
of
the
resource
managers
that
use
the
services
of
IBM
Tivoli
Access
Manager.
Additional
information
about
IBM
Tivoli
Access
Manager
for
Business
Integration
can
be
found
at:
http://www.ibm.com/software/tivoli/products/access-mgr-bus-integration/
The
following
documents
associated
with
IBM
Tivoli
Access
Manager
for
Business
Integration
Version
5.1
are
available
on
the
Tivoli
Information
Center
Web
site:
v
IBM
Tivoli
Access
Manager
for
Business
Integration
Administration
Guide
(SC23-4831-01)
v
IBM
Tivoli
Access
Manager
for
Business
Integration
Problem
Determination
Guide
(GC23-1328-00)
v
IBM
Tivoli
Access
Manager
for
Business
Integration
Release
Notes
(GI11-0957-01)
v
IBM
Tivoli
Access
Manager
for
Business
Integration
Read
This
First
(GI11-4202-00)
IBM
Tivoli
Access
Manager
for
WebSphere
Business
Integration
Brokers
IBM
Tivoli
Access
Manager
for
WebSphere
Business
Integration
Brokers,
available
as
part
of
IBM
Tivoli
Access
Manager
for
Business
Integration,
provides
a
security
solution
for
WebSphere
Business
Integration
Message
Broker,
Version
5.0
and
WebSphere
Business
Integration
Event
Broker,
Version
5.0.
IBM
Tivoli
Access
Manager
for
WebSphere
Business
Integration
Brokers
operates
in
conjunction
with
Tivoli
Access
Manager
to
secure
JMS
publish/subscribe
applications
by
providing
password
and
credentials-based
authentication,
centrally-defined
authorization,
and
auditing
services.
Additional
information
about
IBM
Tivoli
Access
Manager
for
WebSphere
Integration
Brokers
can
be
found
at:
http://www.ibm.com/software/tivoli/products/access-mgr-bus-integration/
The
following
documents
associated
with
IBM
Tivoli
Access
Manager
for
WebSphere
Integration
Brokers,
Version
5.1
are
available
on
the
Tivoli
Information
Center
Web
site:
v
IBM
Tivoli
Access
Manager
for
WebSphere
Business
Integration
Brokers
Administration
Guide
(SC32-1347-00)
xii
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
v
IBM
Tivoli
Access
Manager
for
WebSphere
Business
Integration
Brokers
Release
Notes
(GI11-4154-00)
v
IBM
Tivoli
Access
Manager
for
Business
Integration
Read
This
First
(GI11-4202-00)
IBM
Tivoli
Access
Manager
for
Operating
Systems
IBM
Tivoli
Access
Manager
for
Operating
Systems,
available
as
a
separately
orderable
product,
provides
a
layer
of
authorization
policy
enforcement
on
UNIX
systems
in
addition
to
that
provided
by
the
native
operating
system.
IBM
Tivoli
Access
Manager
for
Operating
Systems,
like
WebSEAL
and
IBM
Tivoli
Access
Manager
for
Business
Integration,
is
one
of
the
resource
managers
that
use
the
services
of
IBM
Tivoli
Access
Manager.
Additional
information
about
IBM
Tivoli
Access
Manager
for
Operating
Systems
can
be
found
at:
http://www.ibm.com/software/tivoli/products/access-mgr-operating-sys/
The
following
documents
associated
with
IBM
Tivoli
Access
Manager
for
Operating
Systems
Version
5.1
are
available
on
the
Tivoli
Information
Center
Web
site:
v
IBM
Tivoli
Access
Manager
for
Operating
Systems
Installation
Guide
(SC23-4829-00)
v
IBM
Tivoli
Access
Manager
for
Operating
Systems
Administration
Guide
(SC23-4827-00)
v
IBM
Tivoli
Access
Manager
for
Operating
Systems
Problem
Determination
Guide
(SC23-4828-00)
v
IBM
Tivoli
Access
Manager
for
Operating
Systems
Release
Notes
(GI11-0951-00)
v
IBM
Tivoli
Access
Manager
for
Operating
Systems
Read
Me
First
(GI11-0949-00)
IBM
Tivoli
Identity
Manager
IBM
Tivoli
Identity
Manager
Version
4.5,
available
as
a
separately
orderable
product,
enables
you
to
centrally
manage
users
(such
as
user
IDs
and
passwords)
and
provisioning
(that
is
providing
or
revoking
access
to
applications,
resources,
or
operating
systems.)
Tivoli
Identity
Manager
can
be
integrated
with
Tivoli
Access
Manager
through
the
use
of
the
Tivoli
Access
Manager
Agent.
Contact
your
IBM
account
representative
for
more
information
about
purchasing
the
Agent.
Additional
information
about
IBM
Tivoli
Identity
Manager
can
be
found
at:
http://www.ibm.com/software/tivoli/products/identity-mgr/
Accessing
publications
online
The
publications
for
this
product
are
available
online
in
Portable
Document
Format
(PDF)
or
Hypertext
Markup
Language
(HTML)
format,
or
both
in
the
Tivoli
software
library:
http://www.ibm.com/software/tivoli/library
To
locate
product
publications
in
the
library,
click
the
Product
manuals
link
on
the
left
side
of
the
library
page.
Then,
locate
and
click
the
name
of
the
product
on
the
Tivoli
software
information
center
page.
Product
publications
include
release
notes,
installation
guides,
user’s
guides,
administrator’s
guides,
and
developer’s
references.
Preface
xiii
Note:
To
ensure
proper
printing
of
publications,
select
the
Fit
to
page
check
box
in
the
Adobe
Acrobat
window
(which
is
available
when
you
click
File
→
Print).
Accessibility
Accessibility
features
help
a
user
who
has
a
physical
disability,
such
as
restricted
mobility
or
limited
vision,
to
use
software
products
successfully.
With
this
product,
you
can
use
assistive
technologies
to
hear
and
navigate
the
interface.
You
also
can
use
the
keyboard
instead
of
the
mouse
to
operate
all
features
of
the
graphical
user
interface.
Contacting
software
support
Before
contacting
IBM
Tivoli
Software
Support
with
a
problem,
refer
to
the
IBM
Tivoli
Software
Support
site
by
clicking
the
Tivoli
support
link
at
the
following
Web
site:
http://www.ibm.com/software/support/
If
you
need
additional
help,
contact
software
support
by
using
the
methods
described
in
the
IBM
Software
Support
Guide
at
the
following
Web
site:
http://techsupport.services.ibm.com/guides/handbook.html
The
guide
provides
the
following
information:
v
Registration
and
eligibility
requirements
for
receiving
support
v
Telephone
numbers,
depending
on
the
country
in
which
you
are
located
v
A
list
of
information
you
should
gather
before
contacting
customer
support
Conventions
used
in
this
book
This
reference
uses
several
conventions
for
special
terms
and
actions
and
for
operating
system-dependent
commands
and
paths.
Typeface
conventions
The
following
typeface
conventions
are
used
in
this
reference:
Bold
Lowercase
commands
or
mixed
case
commands
that
are
difficult
to
distinguish
from
surrounding
text,
keywords,
parameters,
options,
names
of
Java
classes,
and
objects
are
in
bold.
Italic
Variables,
titles
of
publications,
and
special
words
or
phrases
that
are
emphasized
are
in
italic.
Monospace
Code
examples,
command
lines,
screen
output,
file
and
directory
names
that
are
difficult
to
distinguish
from
surrounding
text,
system
messages,
text
that
the
user
must
type,
and
values
for
arguments
or
command
options
are
in
monospace.
Operating
system
differences
This
book
uses
the
UNIX
convention
for
specifying
environment
variables
and
for
directory
notation.
When
using
the
Windows
command
line,
replace
$variable
with
%variable%
for
environment
variables
and
replace
each
forward
slash
(/)
with
a
backslash
(\)
in
directory
paths.
If
you
are
using
the
bash
shell
on
a
Windows
system,
you
can
use
the
UNIX
conventions.
xiv
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Chapter
1.
Introducing
the
IBM
Tivoli
Access
Manager
plug-in
for
Edge
Server
The
plug-in
for
Edge
Server
adds
authentication
and
authorization
functionality
to
the
IBM
WebSphere
Edge
Server
product.
When
implemented
as
an
authorization
service
in
your
secure
domain,
this
plug-in
can
provide
single
signon
solutions
to
resources
within
that
domain.
This
chapter
describes
the
IBM
Tivoli
Access
Manager
security
model
and
the
plug-in
for
Edge
Server
security
enforcement.
System
requirements
Tivoli
Access
Manager
has
specific
software
and
hardware
prerequisites
that
must
be
met
before
it
can
be
installed
and
deemed
fully
functional.
These
include
operating
systems,
hardware
platforms,
and
so
on.
For
the
most
current
information,
see
the
IBM
Tivoli
Access
Manager
for
e-business
Release
Notes.
Tivoli
Access
Manager
security
model
The
plug-in
for
Edge
Server
adds
authentication
and
authorization
control
to
the
Edge
Server
caching
proxy.
To
administer
the
plug-in
for
Edge
Server,
you
need
to
be
familiar
with
the
Tivoli
Access
Manager
model
for
enforcing
security
policies.
The
Tivoli
Access
Manager
model
is
based
on
understanding
the
business
policies
that
must
apply
to
users,
programs,
and
data
in
a
network
environment.
To
establish
a
secure
environment,
Tivoli
Access
Manager
requires
an
administrator
to
define
the
following
entities:
v
Objects
to
be
secured
v
Actions
permitted
on
each
object
v
Users
permitted
to
perform
the
actions
Tivoli
Access
Manager
manages
each
of
these
entities
as
follows:
v
Objects
are
listed
and
defined
in
a
hierarchal
protected
object
name
space
or
object
space.
v
Standard
actions,
such
as
read
and
write,
are
defined
as
permissions.
Administrators
can
also
define
custom
application-specific
actions.
v
Users
and
groups
are
defined
in
a
Tivoli
Access
Manager
supported
user
registry.
Tivoli
Access
Manager
combines
these
concepts
to
form
access
control
lists
(ACLs)
that
consist
of
combinations
of
specific
users
or
groups
and
a
list
of
the
permissions
(actions).
The
administrator
attaches
these
ACLs
to
objects
in
the
object
space.
For
example,
an
administrator
can
control
access
to
the
contents
of
a
Web
server
by
attaching
an
ACL
to
a
file
at
the
top
of
a
hierarchal
file
system
on
a
Web
server.
The
administrator
can
also
choose
to
apply
a
more
restrictive
ACL
further
down
in
the
file
hierarchy.
The
more
restrictive
ACL
overrides
the
ACL
that
is
attached
at
©
Copyright
IBM
Corp.
2001,
2003
1
the
top
of
the
hierarchy.
The
plug-in
for
Edge
Server
enforces
access
control
by
checking
for
the
read
(r),
modify
(m),
or
execute
(x)
permission
on
each
requested
object,
based
on
the
requested
action.
The
Tivoli
Access
Manager
security
model
is
flexible
and
supports
many
different
configurations.
Before
you
use
the
plug-in
for
Edge
Server,
you
need
to
be
familiar
with
Tivoli
Access
Manager
capabilities.
For
more
information,
see
the
IBM
Tivoli
Access
Manager
Base
Administrator’s
Guide.
Plug-in
for
Edge
Server
security
enforcement
The
plug-in
for
Edge
Server
works
with
the
IBM
WebSphere
Edge
Server
to
provide
access
control.
It
sits
at
the
edge
of
an
enterprise
network
where
access
requests
from
clients
outside
the
firewall
are
evaluated.
Edge
Server
consists
of
two
key
components:
v
Caching
proxy
v
Network
dispatcher
The
plug-in
is
invoked
by
the
Edge
Server
caching
proxy
component
on
every
request
to
determine
if
the
user
is
authorized
to
access
the
requested
resource.
The
subsequent
authorization
decision
returned
by
the
plug-in
is
enforced
by
the
caching
proxy.
Although
the
network
dispatcher
component
is
not
required
to
run
the
plug-in,
it
can
be
used
for
load
balancing
across
replicated
servers
in
high
volume
environments.
Generally,
when
a
user
issues
a
request
from
a
browser
to
a
Web
site,
the
object
represented
in
the
URL
corresponds
to
an
object
on
a
Web
server.
The
plug-in
for
Edge
Server
provides
access
control
by
verifying
that
the
user
is
authorized
to
perform
the
requested
action
on
the
Web
server
object.
The
plug-in
does
this
by
authenticating
the
user
against
the
Tivoli
Access
Manager
user
registry
and
authorizing
the
user
against
the
Tivoli
Access
Manager
object
space,
as
illustrated
in
Figure
1
on
page
3.
The
plug-in
returns
status
information
to
the
caching
proxy
indicating
whether
the
user
was
authorized
to
perform
the
requested
action
on
the
object.
The
caching
proxy
uses
this
information
to
either
deny
or
allow
the
requested
action.
When
the
security
policy
permits,
the
Edge
Server
caching
proxy
caches
the
requested
object
to
optimize
performance.
2
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
The
plug-in
for
Edge
Server
provides
access
control
for
the
following
Edge
Server
caching
proxy
configurations:
v
Reverse
proxy
v
Forward
proxy
These
concepts
are
discussed
in
the
following
sections.
Reverse
proxy
access
control
The
Edge
Server
caching
proxy
functions
as
a
reverse
proxy
when
it
is
located
between
a
client
browser
on
the
Internet
and
Web
servers
that
are
located
behind
a
firewall.
In
this
role,
the
caching
proxy
intercepts
user
requests
arriving
from
the
Internet,
forwards
them
to
the
appropriate
host
Web
server,
caches
the
returned
data,
and
delivers
that
data
to
the
client
user
across
the
Internet.
The
plug-in
for
Edge
Server
can
be
used
to
provide
access
control
to
these
inbound
client
requests.
This
is
accomplished
by
configuring
the
public
domain
name
of
the
Web
site
on
the
Edge
Server
caching
proxy
machine
and
specifying
a
route
to
the
corresponding
backend
Web
server,
as
illustrated
in
Figure
2.
Internet Gateway
Browser
Edge Server
CachingProxy
Web Server
Tivoli Access ManagerPolicy Server
Tivoli Access ManagerPlug-in
Tivoli Access ManagerRegistry Server
Figure
1.
Example
of
plug-in
for
Edge
Server
security
enforcement
Internet Gateway
Browser
Edge Servernewbooks.com
CachingProxy
Tivoli Access Manager
Web Serverbackend1.com
Plug-in
Figure
2.
Plug-in
for
Edge
Server
in
a
reverse
proxy
configuration
Chapter
1.
Introducing
the
IBM
Tivoli
Access
Manager
plug-in
for
Edge
Server
3
In
this
example,
the
plug-in
for
Edge
Server
is
configured
to
provide
access
control
to
the
objects
on
newbooks.com.
After
a
user
is
authorized,
the
request
is
routed
to
the
corresponding
backend
server
either
by
the
plug-in
for
Edge
Server,
or
by
a
load
balancing
module,
such
as
the
content-based
routing
module
of
the
Edge
Server
network
dispatcher.
The
plug-in
for
Edge
Server
performs
URL
mapping,
similar
to
the
function
provided
by
the
Proxy
statements
in
the
Edge
Server
caching
proxy
configuration
file.
You
configure
the
plug-in
for
Edge
Server
access
control
by
setting
values
for
parameters
in
the
plug-in
configuration
file,
osdef.conf.
For
this
example
Web
site,
you
would
add
the
following
entries:
[Remote:
/ESproxy/reverse/newbooks.com]
domains
=
newbooks.com
www.newbooks.com
login_method
=
forms
form_login_file
=
http://newbooks.com/pub/login.html
form_login_errorfile
=
http://newbooks.com/pub/loginerr.html
form_logout_url
=
/pub/logout.html
route
=
http://backend1.com
This
entry
configures
the
plug-in
for
Edge
Server
to
perform
the
following
actions:
v
Authorize
all
requests
for
newbooks.com
and
www.newbooks.com
by
consulting
the
ACLs
that
are
attached
to
objects
under
the
entry
/ESproxy/reverse/newbooks.com
in
the
Tivoli
Access
Manager
protected
object
name
space.
v
Use
forms-based
login
as
the
login
method
v
Map
every
URL
to
the
following
Web
server:
backend1.com
In
this
example,
the
administrator
should
attach
the
unauthenticated
ACL
on
the
/pub
directory.
For
more
information
about
the
use
of
the
unauthenticated
ACL,
see
the
IBM
Tivoli
Access
Manager
Base
Administrator’s
Guide.
Note
also
that
if
the
user
submits
a
URL
request
that
matches
/pub/logout.html,
the
user
is
logged
out.
By
default,
the
plug-in
for
Edge
Server
checks
/ESproxy/reverse/domain_name
for
reverse
proxy
requests.
You
can
set
additional
options
for
this
server
definition.
If
you
do
not
specify
a
setting
for
an
option,
the
setting
for
that
option
is
inherited
from
the
[Global]
section
of
the
osdef.conf
configuration
file.
The
plug-in
for
Edge
Server
supports
several
login
methods.
In
addition
to
the
forms-based
login
shown
in
the
sample
configuration,
you
can
also
configure
the
plug-in
for
Edge
Server
to
use:
v
Basic
authentication
v
Client
certificate
authentication
For
information
about
osdef.conf
file
options,
see
Appendix
B,
“Object
space
definition
configuration
file
reference,”
on
page
71.
Forward
proxy
access
control
The
Edge
Server
caching
proxy
functions
as
a
forward
proxy
when
it
is
located
between
a
client
browser
(behind
a
firewall)
and
the
Internet.
The
client
browsers
are
configured
to
direct
requests
to
the
Edge
Server
caching
proxy.
The
forward
caching
proxy
forwards
a
client’s
request
to
a
content
host
located
across
the
Internet,
caches
the
retrieved
data,
and
delivers
the
retrieved
data
to
the
client.
4
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
The
plug-in
for
Edge
Server
can
be
used
to
provide
access
control
to
these
outbound
client
requests,
as
illustrated
in
Figure
3.
By
default,
the
plug-in
for
Edge
Server
checks
/ESproxy/forward/domain_name
for
forward
proxy
requests.
You
can
override
this
default
setting
by
creating
one
or
more
server
definitions
in
the
object
space
definition
configuration
file
as
shown:
[Remote:
/ESproxy/forward/blockedsites]
domains
=
games.com
*.games.com
*.competitor.com
route
=
http://backend2.com
/pub/browsepolicy.html
In
this
example,
all
browser
requests
matching
the
domain
names
games.com,
*.games.com,
or
*.competitor.com
are
redirected
to
the
company’s
browsing
policy
Web
page
located
at
the
following
Web
address:
backend2.com
Alternatively,
you
can
attach
a
Tivoli
Access
Manager
ACL
at
this
location
in
the
object
space.
For
example,
this
ACL
could
deny
all
users
access
to
any
of
the
listed
Web
sites.
Internet Gateway
Edge Server
CachingProxy
Tivoli Access ManagerPlug-in
Web Server Browser
Figure
3.
Plug-in
for
Edge
Server
in
a
forward
proxy
configuration
Chapter
1.
Introducing
the
IBM
Tivoli
Access
Manager
plug-in
for
Edge
Server
5
6
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Chapter
2.
Installing
the
plug-in
for
Edge
Server
This
chapter
describes
how
to
install
and
configure
the
plug-in
for
Edge
Server
on
IBM
AIX,
Red
Hat
Linux,
Sun
Solaris
Operating
Environment
(hereinafter
referred
to
as
Solaris),
and
Microsoft
Windows
platforms.
Note
that
if
your
system
is
currently
set
up
with
supported
versions
of
GSKit,
IBM
SecureWay
Directory
client,
and
the
IBM
Tivoli
Access
Manager
runtime
environment,
you
need
to
install
only
the
plug-in
package.
This
chapter
contains
the
following
sections:
v
“Supported
platforms”
v
“Disk
and
memory
requirements”
v
“Software
prerequisites”
on
page
8
v
“Installing
the
plug-in
for
Edge
Server
on
AIX”
on
page
8
v
“Installing
the
plug-in
for
Edge
Server
on
Linux”
on
page
8
v
“Installing
the
plug-in
for
Edge
Server
on
Solaris”
on
page
9
v
“Installing
the
plug-in
for
Edge
Server
on
Windows”
on
page
9
v
“Configuring
the
plug-in
for
Edge
Server”
on
page
9
Supported
platforms
Tivoli
Access
Manager
Plug-in
for
WebSphere
Edge
Server,
Version
5.1,
is
supported
on
IBM
WebSphere
Edge
Server
version
5.1.
Tivoli
Access
Manager
Plug-in
for
WebSphere
Edge
Server
is
supported
on
the
following
operating
systems:
v
IBM
AIX
5.1.0
and
5.2.0
v
Sun
Solaris
8
and
9
v
Microsoft
Windows
2000
Server
and
Advanced
Servers
(Service
Pack
3)
v
Red
Hat
Enterprise
Linux
2.1
Disk
and
memory
requirements
Tivoli
Access
Manager
Plug-in
for
Edge
Server
has
the
following
disk
and
memory
requirements:
v
15
MB
RAM,
30
MB
recommended.
This
is
the
amount
of
memory
needed
in
addition
to
the
memory
requirements
specified
by
Edge
Server
and
by
any
other
Tivoli
Access
Manager
components.
The
amount
of
memory
needed
by
other
Tivoli
Access
Manager
components
will
depend
on
which
Tivoli
Access
Manager
components
are
installed
on
the
host
system.
For
more
information,
see
the
IBM
Tivoli
Access
Manager
Base
Installation
Guide.
v
15
MB
disk
space,
25
MB
recommended.
This
requirement
is
in
addition
to
the
disk
space
required
by
Edge
Server
and
by
any
other
Tivoli
Access
Manager
components.
v
15
MB
recommended
disk
space
for
ACL
database.
This
is
based
on
the
approximate
requirement
for
an
ACL
database
with
10,000
objects,
equally
spread
across
10
object
spaces
and
about
30
ACLs
attached
to
©
Copyright
IBM
Corp.
2001,
2003
7
10%
of
the
objects.
Except
for
the
policy
server,
the
size
is
tripled
to
account
for
a
backup
copy
and
an
additional
copy
created
during
replication.
v
10
MB
disk
space
for
log
files.
This
is
the
recommended
disk
space
required
in
addition
to
the
space
required
for
the
software
components.
Software
prerequisites
A
Tivoli
Access
Manager
secure
domain
must
be
established
prior
to
installing
Tivoli
Access
Manager
Plug-in
for
Edge
Server.
The
Tivoli
Access
Manager
secure
domain
is
established
when
you
install
the
Tivoli
Access
Manager
policy
server.
This
policy
server
is
distributed
on
the
IBM
Tivoli
Access
Manager
Base
CD
for
your
operating
system.
Installing
the
plug-in
for
Edge
Server
on
AIX
The
following
steps
show
you
how
to
install
components
necessary
for
the
plug-in
for
Edge
Server.
Note:
Before
you
install
the
plug-in
package,
ensure
that
you
install
prerequisite
software
listed
in
the
IBM
Tivoli
Access
Manager
for
e-business
Release
Notes.
1.
Log
in
to
the
system
as
root.
2.
Insert
the
IBM
Tivoli
Access
Manager
Web
Security,
Version
5.1,
for
AIX
CD.
3.
To
install
the
Plug-in
for
Edge
Server
package
in
the
default
location,
enter
the
following:
installp
-c
-a
-g
-X
-d
/dev/cd0
PDPlgES
4.
To
complete
the
installation
of
the
plug-in
for
Edge
Server,
follow
the
instructions
in
“Configuring
the
plug-in
for
Edge
Server”
on
page
9.
Installing
the
plug-in
for
Edge
Server
on
Linux
The
following
steps
show
you
how
to
install
components
necessary
for
the
plug-in
for
Edge
Server.
Note:
Before
you
install
the
plug-in
package,
ensure
that
you
install
prerequisite
software
listed
in
IBM
Tivoli
Access
Manager
for
e-business
Release
Notes.
The
Tivoli
Access
Manager
Runtime
Environment
is
not
required
for
a
Linux
installation.
1.
Log
in
to
the
system
as
root.
2.
Insert
the
IBM
Tivoli
Access
Manager
Web
Security,
Version
5.1,
for
Linux
CD.
3.
Change
to
the
directory
/mnt/cdrom/linux,
where
/mnt/cdrom
is
the
mount
point
for
your
CD.
4.
To
install
the
plug-in
for
Edge
Server
package
in
the
default
location,
enter
the
following:
rpm
-i
PDPlgES-PD-5.1.0-0.i386.rpm
5.
To
complete
the
installation
of
the
plug-in
for
Edge
Server,
follow
the
instructions
in
“Configuring
the
plug-in
for
Edge
Server”
on
page
9.
8
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Installing
the
plug-in
for
Edge
Server
on
Solaris
The
following
steps
show
you
how
to
install
components
necessary
for
the
plug-in
for
Edge
Server.
1.
Log
in
to
the
system
as
root.
2.
Insert
the
IBM
Tivoli
Access
Manager
Web
Security,
Version
5.1,
for
Solaris
CD.
3.
Change
to
the
/cdrom/cdrom0/solaris
directory.
4.
To
install
the
plug-in
for
Edge
Server
package,
enter
the
following:
pkgadd
-d
/cdrom/cdrom0/solaris
-a
/cdrom/cdrom0/solaris/pddefault
PDPlgES
5.
To
complete
the
installation
of
the
Plug-in
for
Edge
Server,
follow
the
instructions
in
“Configuring
the
plug-in
for
Edge
Server”
on
page
9.
Installing
the
plug-in
for
Edge
Server
on
Windows
The
following
steps
show
you
how
to
install
components
necessary
for
the
plug-in
for
Edge
Server.
1.
Log
in
to
the
system
as
a
user
with
administrator
privileges.
2.
Insert
the
IBM
Tivoli
Access
Manager
Web
Security,
Version
5.1,
for
Windows
CD.
3.
Run
the
setup.exe
file
in
the
following
location:
cdrom_drive\windows\PolicyDirector\Disk
Images\Disk1
4.
From
the
Select
Packages
window,
select
the
plug-in
for
Edge
Server
package.
5.
To
complete
the
installation
of
the
plug-in
for
Edge
Server,
follow
the
instructions
in
“Configuring
the
plug-in
for
Edge
Server”
on
page
9.
Configuring
the
plug-in
for
Edge
Server
The
plug-in
for
Edge
Server
is
configured
using
the
pdconfig
command.
This
utility
accomplishes
the
following
tasks:
v
Creates
a
Tivoli
Access
Manager
identity
for
the
plug-in
for
Edge
Server.
v
Creates
a
Tivoli
Access
Manager
protected
object
space
for
the
plug-in
for
Edge
Server.
v
On
the
Windows
platform
only,
configures
the
Edge
Server
caching
proxy
to
automatically
load
the
plug-in
for
Edge
Server
at
application
startup.
To
configure
the
plug-in
for
Edge
Server,
follow
these
steps:
1.
To
start
the
configuration
utility,
enter
pdconfig.
The
Tivoli
Access
Manager
Configuration
Menu
is
displayed.
Note:
Ensure
you
have
write
permissions
on
the
directory
from
which
you
run
pdconfig.
2.
Select
1
for
The
IBM
Tivoli
Access
Manager
Plug-in
for
Edge
Server.
Configuration.
3.
When
prompted,
enter
the
following
information:
v
The
port
number
for
the
Edge
Server
caching
proxy.
The
default
port
number
is
80.
v
The
Tivoli
Access
Manager
administrative
user
ID
and
password.
For
example,
enter
sec_master
and
its
associated
password.
The
configuration
utility
completes
the
following
tasks:
v
Creates
registry
objects
for
the
server.
v
Adds
the
server
to
the
security
groups,
ivacld-servers
and
SecurityGroup.
Chapter
2.
Installing
the
plug-in
for
Edge
Server
9
v
Creates
an
SSL
certificate.
v
Obtains
an
SSL
signed
certificate
from
the
Tivoli
Access
Manager
policy
server.
v
Configures
the
Edge
Server
caching
proxy
to
use
the
plug-in
for
Edge
Server
by
setting
directives
in
the
Edge
Server
caching
proxy
configuration
file,
ibmproxy.conf.
v
Restarts
the
Edge
Server
caching
proxy
process,
ibmproxy.
Next,
the
configuration
utility
starts
the
plug-in
for
Edge
Server
object
space
manager
utility,
by
using
the
wesosm
command.
This
utility
updates
the
Tivoli
Access
Manager
object
space
to
create
a
new
object
space
container
for
the
plug-in
for
Edge
Server.
Configuration
of
the
plug-in
for
Edge
Server
is
now
complete.
The
Edge
Server
caching
proxy
is
now
running
with
the
plug-in
for
Edge
Server
loaded.
The
administrative
user,
sec_master,
can
be
used
to
access
the
caching
proxy’s
home
page.
If
you
want
to
use
SSL
communications
between
the
Edge
Server
plug-in
and
LDAP
you
will
need
to
configure
this
manually.
The
PolicyDir_LDAP_SSL_Keyfile
and
PolicyDir_LDAP_SSL_Keyfile_Password
parameters
in
the
ibmwesas.conf
configuration
file
are
used
to
configure
SSL
between
the
plug-in
and
LDAP.
Upgrading
the
plug-in
for
Edge
Server
The
configuration
tool
for
the
earlier
versions
of
the
plug-in
automatically
replaced
user
configuration
files
during
the
unconfiguration
process,
which
sometimes
caused
the
loss
of
user
configuration
information.
The
plug-in
for
Edge
Server,
Version
5.1,
does
not
replace
user
configuration
files
during
the
unconfiguration
process.
When
upgrading
from
an
existing
version
of
the
plug-in
for
Edge
Server,
you
need
to
back
up
all
user
modified
configuration
files,
such
as
ibmwesas.conf,
osdef.conf,
ibmproxy.conf,
before
unconfiguring
the
plug-in.
10
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Chapter
3.
Administering
the
plug-in
for
Edge
Server
This
chapter
provides
the
concepts,
administrative
procedures,
and
technical
reference
information
for
using
the
plug-in
for
Edge
Server
to
manage
the
resources
of
your
secure
domain.
This
chapter
contains
the
following
sections:
v
“Managing
user
accounts”
on
page
11
v
“Creating
a
Tivoli
Access
Manager
object
space”
on
page
11
v
“Starting
and
stopping
the
plug-in
for
Edge
Server”
on
page
13
v
“Configuration
files”
on
page
13
v
“Log
files”
on
page
16
v
“Configuring
the
login
method”
on
page
17
v
“Configuring
tag-value
pair
support”
on
page
21
Managing
user
accounts
IBM
Tivoli
Access
Manager
maintains
and
manages
user
accounts
through
the
pdadmin
command
line
interface.
Users
and
groups
are
created,
deleted,
and
modified
using
this
interface.
The
plug-in
authenticates
a
user
by
verifying
that
the
submitted
user
information
matches
a
user
entry
in
the
Tivoli
Access
Manager
registry.
The
plug-in
also
verifies
that
the
user
account
status
is
valid.
All
password
policies
for
users
are
set
through
Tivoli
Access
Manager
and
conveyed
to
the
plug-in
during
authentication.
The
plug-in
does
not
maintain
any
password
policy
information
instead
it
relies
on
Tivoli
Access
Manager
to
maintain
information
such
as
max-login-failures,
account-expiry-date,
and
max-password-age.
During
authentication,
the
plug-in
verifies
that
the
user
account
is
valid
and
ensures
that
the
user’s
password
has
not
expired.
If
the
user
account
is
disabled,
the
user
fails
authorization.
However,
if
the
password
has
expired
and
a
change
password
form
was
configured
for
the
plug-in,
then
the
user
is
presented
with
the
form
to
change
the
expired
password.
Creating
a
Tivoli
Access
Manager
object
space
Tivoli
Access
Manager
uses
a
protected
object
name
space
to
represent
objects
that
need
to
have
access
control
policies
applied.
The
protected
object
space
can
include
resources
on
a
Web
server.
The
simplest
way
to
add
Web
resources
to
the
object
space
is
to
import
the
Web
server
file
system
and
apply
Tivoli
Access
Manager
access
control
lists
(ACLs)
as
needed.
The
plug-in
for
Edge
Server
provides
an
object
space
manager
utility
that
adds
resources
to
the
Tivoli
Access
Manager
object
space.
The
utility
is
invoked
with
the
wesosm
command.
You
can
use
wesosm
to
generate
the
object
space
for
both
the
Edge
Server
caching
proxy
and
for
Web
servers
that
the
plug-in
for
Edge
Server
protects.
Note:
For
more
information
about
the
wesosm
command,
see
Appendix
C,
“Command
reference,”
on
page
85.
The
following
sections
describe
how
to
add
Web
resources
to
the
protected
object
space:
v
“Creating
an
object
space
for
the
caching
proxy”
on
page
12
©
Copyright
IBM
Corp.
2001,
2003
11
v
“Creating
an
object
space
for
other
Web
servers”
Creating
an
object
space
for
the
caching
proxy
Although
the
Edge
Server
caching
proxy
is
a
proxy,
it
can
function
like
a
Web
server
when
requests
are
made
directly
to
the
primary
domain
name
of
the
Edge
Server
caching
proxy
machine.
Typically,
informational
and
error
messages
are
stored
in
the
Web
space
of
the
proxy.
The
plug-in
for
Edge
Server
enforces
access
control
on
the
objects
managed
by
the
Edge
Server
caching
proxy.
Each
object
that
needs
to
be
secured
must
be
defined
in
the
Tivoli
Access
Manager
object
space.
There
are
two
methods
for
adding
objects
to
the
object
space.
You
can
add
objects
to
the
object
space
manually
by
using
the
pdadmin
command.
The
pdadmin
command
contains
command
line
options
for
creating
new
object
spaces
and
for
adding,
modifying,
and
deleting
objects.
For
more
information,
see
the
IBM
Tivoli
Access
Manager
Command
Reference.
You
can
also
add
a
series
of
Web
resources
to
the
object
space
by
using
the
query_contents
utility
to
get
an
inventory
of
the
objects
in
a
Web
hierarchy.
This
method
is
discussed
in
“Creating
an
object
space
for
other
Web
servers”
on
page
12.
The
following
example
server
definition
in
the
configuration
file
osdef.conf
represents
an
Edge
Server
caching
proxy
named
bookproxy.com:
[Local:
/ESproxy/bookproxy.com]
domains
=
bookproxy.com
query_command
=
http://bookproxy.com/cgi-bin/query_contents?dirlist=/
When
you
configure
the
plug-in
for
Edge
Server
at
installation
time,
the
wslconfig
utility
executes
the
wesosm
command
to
generate
the
default
object
space
for
the
Edge
Server
caching
proxy.
The
default
object
space
contains
the
following
container
objects:
/ESproxy
/Esproxy/proxy_host_name
/ESproxy/forward
/ESproxy/reverse
After
the
objects
are
created,
you
can
place
ACLs
at
the
appropriate
locations
in
the
object
space
for
the
Edge
Server
caching
proxy.
Creating
an
object
space
for
other
Web
servers
Use
the
object
space
manager
command,
wesosm,
to
query
a
remote
Web
server’s
file
system
to
create
corresponding
entries
in
the
Tivoli
Access
Manager
object
space.
The
object
space
manager
reads
the
osdef.conf
configuration
file
and
creates
object
entries
for
each
server
definition
in
the
file.
Use
the
query_contents
utility
to
import
a
Web
server’s
file
system
into
the
protected
object
space.
The
query_contents
utility
is
located
in
install_dir\bin
on
Windows
systems
or
/opt/pdweb-lite/bin
on
UNIX
systems.
Copy
this
utility
into
the
cgi-bin
directory
on
the
target
Web
server.
Also,
specify
the
root
location
of
the
Web
server’s
files
by
setting
the
DOCROOT
parameter
in
C:\WINNT\query_contents.cfg
on
Windows
systems,
or
setting
the
DOCROOTDIR
parameter
in
query_contents.sh
on
UNIX
systems.
For
more
information
about
the
query_contents
utility,
see
the
IBM
Tivoli
Access
Manager
WebSEAL
Administrator’s
Guide.
12
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
After
you
have
configured
the
query_contents
utility,
add
an
entry
to
the
object
space
definition
configuration
file
that
tells
the
wesosm
command
how
to
query
the
remote
Web
server’s
file
system.
For
example,
add
the
following
entry
in
the
configuration
file:
[Remote:
/ESproxy/reverse/newbooks.com]
domains
=
newbooks.com
www.newbooks.com
...
query_command
=
http://backend1.com/cgi-bin/query_contents?dirlist=/
After
the
entry
has
been
added
to
the
configuration
file,
run
the
object
space
manager
from
the
plug-in
for
Edge
Server
machine
as
shown:
wesosm
-run
-infile
location_of_osdef.conf
-verbose
The
wesosm
command
connects
to
the
Web
server
to
query
its
file
system.
Next,
it
connects
to
the
Tivoli
Access
Manager
policy
server
to
create
entries
in
the
object
space
underneath
/ESproxy/reverse/newbooks.com.
If
a
server
definition
does
not
have
a
query_contents
utility
associated
with
it,
only
the
root
branch
is
created.
You
can
attach
ACLs
in
appropriate
locations
after
the
object
space
has
been
created.
You
also
can
use
the
wesosm
command
to
maintain
the
object
space
by
pruning
any
obsolete
entries
that
might
accumulate
over
time.
To
remove
obsolete
entries
from
the
object
space,
run
the
wesosm
command
with
the
following
options:
wesosm
-run
-infile
location_of_osdef.conf
-clean
-verbose
Starting
and
stopping
the
plug-in
for
Edge
Server
To
manually
start
the
Edge
Server
caching
proxy
and
load
the
plug-in
for
Edge
Server:
v
On
UNIX
systems,
use
the
wslstartwte
command.
Note:
You
can
add
the
wslstartwte
utility
to
UNIX
startup
scripts
to
automatically
start
the
Edge
Server
caching
proxy
and
the
plug-in
for
Edge
Server
whenever
a
system
restarts.
v
On
Windows
systems,
start
the
IBM
Caching
Proxy
service.
To
stop
the
Edge
Server
caching
proxy
UNIX
systems:
v
On
UNIX
systems,
use
the
wslstopwte
command:
v
On
Windows
systems,
stop
the
IBM
Caching
Proxy
service.
Configuration
files
The
plug-in
for
Edge
Server
configuration
files
are
created
and
placed
on
the
filesystem
when
the
plug-in
for
Edge
Server
is
installed
and
configured.
You
can
manually
modify
these
files
after
initial
configuration.
The
configuration
files
are
located
in
one
of
the
following
directories:
v
On
UNIX
systems:
/opt/pdweb-lite/etc
v
On
Windows
systems:
install_dir\etc
Configuration
files
are
described
in
the
following
sections:
v
“Base
configuration
file
(ibmwesas.conf)”
on
page
14
Chapter
3.
Administering
the
plug-in
for
Edge
Server
13
v
“Object
space
definition
configuration
file
(osdef.conf)”
on
page
14
v
“User
mapping
configuration
file
(usermap.conf)”
on
page
16
Base
configuration
file
(ibmwesas.conf)
The
base
configuration
file
is
named
ibmwesas.conf.
The
wslconfig
utility
initializes
this
file
when
the
plug-in
for
Edge
Server
is
installed
and
configured.
This
file
contains
entries
that
are
used
to
initialize
and
start
the
plug-in
for
Edge
Server.
Typically,
you
do
not
need
to
modify
this
file
after
initial
configuration.
The
ibmwesas.conf
file
contains
entries
that
specify
the
following
values:
v
Tivoli
Access
Manager
Lightweight
Directory
Access
Protocol
(LDAP)
configuration
settings
These
include
LDAP
host
and
port
numbers.
When
Tivoli
Access
Manager
communication
with
the
LDAP
server
is
over
Secure
Sockets
Layer
(SSL),
the
SSL
configuration
values
are
included
here.
v
Tivoli
Access
Manager
configuration
values:
–
Database
replication
mode
(local
or
remote)
–
Database
location
–
Audit
file
location
–
Cache
refresh
interval
–
Location
of
the
SSL
configuration
file
containing
certificate
informationv
Lightweight
Third
Party
Authentication
(LTPA)
cookie
single
signon
settings
v
WebSEAL
cookie
single
signon
settings
v
Location
of
the
osdef.conf
object
space
definition
file
v
Location
of
the
usermap.conf
user
mapping
file
For
more
information
on
the
ibmwesas.conf
file,
see
Appendix
A,
“Base
configuration
file
reference,”
on
page
69.
Object
space
definition
configuration
file
(osdef.conf)
The
object
space
definition
configuration
file
is
named
osdef.conf.
The
osdef.conf
file
specifies
configuration
settings
that
the
plug-in
for
Edge
Server
uses
to
enforce
access
control
for
all
client
requests.
The
object
space
definition
configuration
file
has
its
settings
grouped
into
the
following
sections:
v
[Global]
Specifies
settings
that
apply
to
all
requests
that
are
not
explicitly
overwritten
in
another
section
([Local]
or
[Remote]).
v
[Local]
Specifies
settings
that
apply
to
requests
for
objects
on
the
Edge
Server
caching
proxy.
v
[Remote]
Specifies
settings
that
apply
to
requests
for
objects
on
remote
Web
servers.
v
[SSO]
Specifies
single
signon
definitions
and
settings
that
the
plug-in
for
Edge
Server
can
use
to
pass
authentication
information
to
a
Web
server.
The
[Global]
section
of
the
osdef.conf
file
includes
the
following
configuration
options:
v
Administrator
name
and
password
v
Enable
or
disable
updating
of
the
object
space
14
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
v
Object
space
locations
for
the
object
space
root,
forward
proxy
entries,
and
reverse
proxy
entries
v
File
system
type
v
URL
resolution
using
reverse
Domain
Name
System
(DNS)
lookup
v
Login
method
–
None
It
is
recommended
that
you
use
the
Tivoli
Access
Manager
unauthenticated
ACL
rather
than
the
None
login
type.
–
Basic
authentication
–
Forms-based
login
–
Certificatesv
Forms-based
login
settings
Includes
forms
file
locations,
error
file
locations,
password
handling,
and
security
type
to
be
used
for
secure
form
login.
v
Cache
size
and
cache
timeout
values
for
storing
authenticated
user
information
v
Logging
message
settings
The
[Local]
section
of
the
osdef.conf
file
includes
the
following
configuration
options:
v
Domain
names
v
Login
method
v
Query
command
settings
These
values
are
used
to
collect
object
space
information
for
the
local
Edge
Server
caching
proxy
objects.
The
[Remote]
section
of
the
osdef.conf
file
contains
definitions
for
each
remote
server
that
is
being
secured
by
the
plug-in
for
Edge
Server.
The
settings
for
each
server
include:
v
Domain
names
v
Login
method
and
supporting
files
v
Query
commands
v
SSL
access
requirements
v
Single
signon
options
v
Routing
options
The
[SSO]
section
of
the
osdef.conf
file
contains
single
signon
definitions
and
settings
for
single
signon
configurations.
The
plug-in
for
Edge
Server
can
skip
the
authentication
step
if
a
user
has
already
been
authenticated.
The
plug-in
for
Edge
Server
can
also
pass
single
signon
information
to
a
Web
server
as
either
an
HTTP
header
or
a
cookie.
The
following
single
signon
types
are
predefined:
v
IBM
WebSphere
LTPA
cookie
v
Tivoli
Access
Manager
WebSEAL
failover
cookie
v
CDAS
module
single
signon
The
plug-in
for
Edge
Server
provides
several
predefined
macros
that
you
can
use
to
format
single
signon
information.
For
information
about
these
macros
and
for
examples
of
formatted
single
signon
information,
see
the
sample
entries
in
the
osdef.conf
file.
Chapter
3.
Administering
the
plug-in
for
Edge
Server
15
The
plug-in
for
Edge
Server
supports
many
different
configuration
scenarios.
Accordingly,
many
configuration
options
can
be
adjusted.
The
osdef.conf
configuration
file
documents
each
option
in
detail
and
provides
a
default
and
sample
value
for
each
option.
After
you
develop
a
basic
understanding
of
the
plug-in
for
Edge
Server,
you
can
easily
customize
and
configure
it
to
work
in
your
environment.
The
plug-in
for
Edge
Server
runs
well
using
default
values.
Therefore,
you
do
not
need
to
set
every
option
to
use
it
effectively.
Set
only
the
relevant
options.
For
more
information
on
the
osdef.conf
file,
see
Appendix
B,
“Object
space
definition
configuration
file
reference,”
on
page
71.
User
mapping
configuration
file
(usermap.conf)
The
usermap.conf
file
is
used
to
map
single
signon
and
certificate
users
to
Tivoli
Access
Manager
users.
For
more
information
about
the
user
mapping
file,
see
comments
provided
in
the
usermap.conf
file.
The
usermap.conf
file
is
located
in
one
of
the
following
directories:
v
For
UNIX
systems:
/opt/pdweb-lite/etc
v
For
Windows
systems:
install_dir\etc
Log
files
The
plug-in
for
Edge
Server
logs
events
to
the
event
log
file
of
the
Edge
Server
caching
proxy.
You
can
examine
this
log
file
to
view
the
actions
that
the
plug-in
for
Edge
Server
has
taken.
The
log
file
on
UNIX
systems
is
as
follows:
/opt/ibm/edge/cp/server_root/logs/event.date
The
log
file
on
Windows
systems
is
as
follows:
C:\Program
Files\IBM\edge\cp\Logs\event.date
Figure
4
on
page
17
shows
an
excerpt
from
an
event
log
file.
16
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Configuring
the
login
method
The
login
method
specifies
the
manner
in
which
the
user
presents
credentials
to
the
plug-in
for
authentication.
The
plug-in
supports
the
following
login
methods
which
are
configured
through
the
object
space
definition
configuration
file,
osdef.conf.
The
login
methods
are
described
in
the
following
sections:
v
“Basic
Authentication”
on
page
18
v
“Form
login”
on
page
18
v
“Client
certificates”
on
page
20
[03/15/02
10:04:53
1]
--------------------------------------------
[03/15/02
10:04:53
1]
Entering
Initialization
Plugin:
WTESeal_Init()
[03/15/02
10:04:53
1]
Initialization
of
configuration
settings
succeeded
[03/15/02
10:04:55
1]
Initialization
of
WebSEAL
cookie
module
succeeded
[03/15/02
10:04:55
1]
Initializing
attribute
list
[03/15/02
10:04:55
1]
[00]:
azn_init_audit_file
[03/15/02
10:04:55
1]
[01]:
azn_init_cache_refresh_interval
[03/15/02
10:04:55
1]
[02]:
azn_init_cfg_file
[03/15/02
10:04:55
1]
[03]:
azn_init_db_file
[03/15/02
10:04:55
1]
[04]:
azn_init_ldap_bind_dn
[03/15/02
10:04:55
1]
[05]:
azn_init_ldap_bind_pwd
[03/15/02
10:04:55
1]
[06]:
azn_init_ldap_host
[03/15/02
10:04:55
1]
[07]:
azn_init_ldap_port
[03/15/02
10:04:55
1]
[08]:
azn_init_listen_flags
[03/15/02
10:04:55
1]
[09]:
azn_init_mode
[03/15/02
10:04:55
1]
AZN
API
client
library
version
4.1.0
(Build
020915)
[03/15/02
10:04:55
1]
Initialization
of
Access
Manager
succeeded
[03/15/02
10:04:55
1]
Exiting
Initialization
Plugin:
WTESeal_Init()
[03/15/02
10:04:55
1]
Waiting
for
connections...
[03/15/02
10:06:02
2560]
[03/15/02
10:06:02
2560]
---
Accepted
a
non-secure
connection
---
[03/15/02
10:06:02
2560]
Entering
PreExit
Plugin:
WTESeal_PreExit()
[03/15/02
10:06:02
2560]
User
from
110.120.130.140
submitted
request:
GET
/
[03/15/02
10:06:02
2560]
Login
method
for
this
request
is
basic
[03/15/02
10:06:02
2560]
Checking
authorization
header
for
reverse
proxy
mode
[03/15/02
10:06:02
2560]
Successfully
extracted
user
’joe’
from
authorization
header
[03/15/02
10:06:02
2560]
Exiting
PreExit
Plugin:
WTESeal_PreExit()
[03/15/02
10:06:02
2560]
[03/15/02
10:06:02
2560]
Entering
Authorization
Plugin:
WTESeal_Authorize()
[03/15/02
10:06:02
2560]
HTTP
Headers:
Host:
newbooks.com
Authorization:
Basic
Yah7dglDai84qBXf=
[03/15/02
10:06:02
2560]
Authenticating
user
’joe’
through
Access
Manager
[03/15/02
10:06:02
2560]
Authentication
succeeded
for
user
’joe’
[03/15/02
10:06:02
2560]
Creating
LDAP
identity
for
user
’joe’
[03/15/02
10:06:02
2560]
Loading
credentials
to
authorize
user
’joe’
[03/15/02
10:06:03
2560]
Checking
access
(r)
on
ACL
string
/ESproxy/reverse/newbooks.com
[03/15/02
10:06:03
2560]
Permission
was
granted
to
access
object
[03/15/02
10:06:03
2560]
User
’joe’
was
successfully
authorized
(return
code
=
200)
[03/15/02
10:06:03
2560]
Routing
request
to
http://backend1.com/
using
reverse
proxy
route
[03/15/02
10:06:03
2560]
Exiting
Authorization
Plugin:
WTESeal_Authorize()
Figure
4.
Event
log
file
excerpt
Chapter
3.
Administering
the
plug-in
for
Edge
Server
17
Basic
Authentication
The
user
logs
in
using
basic
authentication
when
the
plug-in
challenges
the
browser
for
a
user
ID
and
password.
The
user
is
prompted
by
the
browser
to
supply
the
user
ID
and
password,
which
is
subsequently
submitted
to
the
plug-in
for
authentication.
After
authentication
succeeds,
the
user
might
be
presented
with
a
form
to
change
an
expired
password.
The
following
example
illustrates
a
configuration
for
newbooks.com
where
the
user
authenticates
using
basic
authentication,
and
is
presented
with
a
form
to
change
the
password
when
it
expires.
[Remote:
/ESproxy/reverse/newbooks.com]
domains
=
newbooks.com
www.newbooks.com
route
=
http://backend1.com
#
Specify
the
login
method
login_method
=
basic
#
Change
password
form
form_chgpasswd_file
=
/opt/pdweb-lite/samples/forms/formchgpwd2.html
#
Change
password
using
change
password
URL
form_chgpasswd_submit_url
=
/pub/chgpasswd
form_chgpasswd_response_url
=
/pub/passwdchanged.html
form_chgpasswd_url_recovery
=
no
The
example
illustrates
the
following
sequence:
1.
The
user
authenticates
using
basic
authentication.
2.
After
authentication
succeeds,
the
user
is
presented
with
a
form
to
change
the
expired
password.
3.
The
user
submits
the
change
password
form
to
the
following
URL:
http://newbooks.com/pub/chgpasswd
4.
After
the
password
is
successfully
changed
by
the
plug-in,
the
browser
is
redirected
to
the
following
URL:
http://newbooks.com/pub/passwdchanged.html
Form
login
The
user
logs
in
using
form
login
when
the
plug-in
sends
a
login
form
to
the
user
to
obtain
the
user
ID
and
password.
The
user
fills
out
the
form
and
submits
it
to
the
plug-in
for
authentication.
When
the
user
submits
the
login
form,
the
plug-in
uses
one
of
the
following
three
methods
to
detect
the
submission
of
the
login
form.
v
Pre-login
cookie
v
Form
signature
v
Login
URL
When
neither
the
form
signature
nor
the
login
URL
is
configured,
the
plug-in
uses
a
pre-login
cookie
to
detect
the
submission
of
the
login
form.
It
creates
this
cookie
when
it
sends
the
login
form
to
the
browser.
When
the
user
submits
the
authentication
form
along
with
this
cookie,
the
plug-in
authenticates
the
user.
The
form
signature
is
a
hidden
name=value
assignment
in
the
login
form.
When
the
user
submits
a
login
form
that
matches
the
configured
form
signature,
the
plug-in
extracts
the
user’s
information
from
the
form
to
authenticate
the
user.
Note
that
the
form
signature
should
only
be
used
if
the
plug-in
is
configured
to
route
the
request
to
the
backend
server.
18
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
The
login
URL
is
another
method
for
the
plug-in
to
detect
the
submission
of
the
login
form.
If
the
submitted
URL
matches
the
configured
login
URL,
the
plug-in
extracts
the
user’s
information
from
the
form
to
authenticate
the
user.
If
either
the
form
signature
or
the
login
URL
is
configured,
then
the
pre-login
cookie
is
not
used.
It
is
expected
that
the
login
form
either
contains
the
form
signature,
or
is
submitted
to
the
login
URL.
Using
either
configuration,
the
user
can
submit
a
login
form
to
the
plug-in
for
authentication,
even
if
the
current
resource
the
user
is
accessing
does
not
require
authenticated
access.
This
might
be
appropriate
for
Web
sites
where
every
user
is
not
necessarily
required
to
authenticate.
Similarly,
a
user’s
password
can
be
changed
(even
if
it
has
not
expired)
when
the
user
submits
the
change
password
form
to
the
plug-in.
When
the
plug-in
detects
the
submission
of
the
change
password
form,
using
either
the
change
password
form
signature
or
the
change
password
URL,
it
changes
the
user’s
password.
The
sample
forms
referenced
in
these
examples
are
copied
to
the
file
system
when
the
plug-in
is
installed.
These
forms
can
be
modified
to
contain
background
pictures
and
images
to
decorate
the
form.
Ensure
that
all
references
to
images
in
the
login
form
do
not
require
authentication
to
access,
and
supply
the
absolute
URL
when
referencing
an
image
or
background
picture
in
the
form.
The
following
example
illustrates
a
configuration
for
newbooks.com
where
the
user
authenticates
using
the
form
signature.
[Remote:/ESproxy/reverse/newbooks.com]
domains
=
newbooks.com
www.newbooks.com
route
=
http://backend1.com
#
Specify
the
login
method
login_method
=
forms
[Global]
#
login
and
logout
forms
form_login_file
=
/opt/pdweb-lite/samples/forms/formlogin1.html
form_login_errorfile
=
/opt/pdweb-lite/samples/forms/formerror1.html
form_logout_file
=
/opt/pdweb-lite/samples/forms/formlogout.html
#
Form
login
using
login
signature
#form_login_url
=
/account/greeting
form_signature_login
=
FormType=LoginForm
form_logout_url
=
/pub/logout
#
Change
password
form
form_chgpasswd_file
=
/opt/pdweb-lite/samples/forms/formchgpwd1.html
#
Change
password
using
change
password
signature
#form_chgpasswd_submit_url
=
/pub/chgpasswd
form_signature_chgpasswd
=
FormType=ChangePasswordForm
form_chgpasswd_response_url
=
/pub/passwdchanged.html
form_chgpasswd_url_recovery
=
no
The
example
illustrates
the
following
sequence:
1.
The
user
submits
the
login
form
to
the
plug-in.
2.
The
plug-in
detects
the
submission
of
the
login
form
using
the
login
form
signature.
3.
After
authentication
succeeds,
the
user
is
presented
with
a
form
to
change
the
expired
password.
4.
The
user
submits
the
change
password
form
to
the
plug-in.
5.
The
plug-in
detects
the
submission
of
the
change
password
form
using
the
change
password
form
signature.
Chapter
3.
Administering
the
plug-in
for
Edge
Server
19
6.
After
the
password
is
successfully
changed
by
the
plug-in,
the
browser
is
redirected
to
the
following
URL:
http://newbooks.com/pub/passwdchanged.html
The
following
example
illustrates
a
configuration
for
newbooks.com
where
the
user
authenticates
using
the
login
URL.
[Remote:/ESproxy/reverse/newbooks.com]
domains
=
newbooks.com
www.newbooks.com
route
=
http://backend1.com
#
Specify
the
login
method
login_method
=
forms
#
Login
and
logout
forms
form_login_file
=
/opt/pdweb-lite/samples/forms/formlogin2.html
form_login_errorfile
=
/opt/pdweb-lite/samples/forms/formerror2.html
form_logout_file
=
/opt/pdweb-lite/samples/forms/formlogout.html
#
Form
login
using
login
URL
#form_signature_login
=
FormType=LoginForm
form_login_url
=
/account/greeting
form_logout/url
=
/pub/logout
#
Change
password
form
form_chgpasswd_file
=
/opt/pdweb-lite/samples/forms/formchgpwd2.html
#
Change
password
using
change
password
URL
#form_signature_chgpasswd
=
FormType=ChangePasswordForm
form_chgpasswd_submit_url
=
/pub/chgpasswd
form_chgpasswd_response_url
=
/pub/passwdchanged.html
form_chgpasswd_url_recovery
=
no
The
example
illustrates
the
following
sequence:
1.
The
user
submits
the
login
form
to
the
following
URL:
http://newbooks.com/account/greeting
2.
The
plug-in
detects
the
submission
of
the
login
form
using
the
login
URL.
3.
After
authentication
succeeds,
the
user
is
presented
with
a
form
to
change
the
expired
password.
4.
The
user
submits
the
change
password
form
to
the
following
URL:
http://newbooks.com/pub/chgpasswd
5.
The
plug-in
detects
the
submission
of
the
change
password
form
using
the
change
password
URL.
6.
After
the
password
is
successfully
changed
by
the
plug-in,
the
browser
is
redirected
to
the
following
URL:
http://newbooks.com/pub/passwdchanged.html
Client
certificates
The
user
logs
in
using
a
client
certificate
when
the
caching
proxy
challenges
the
browser
for
a
client
certificate.
The
user
is
prompted
by
the
browser
to
select
an
installed
certificate,
which
is
subsequently
submitted
to
the
plug-in
for
authentication.
Configuration
of
client
certificate
authentication
involves
configuring
the
caching
proxy
to
accept
SSL
connections,
and
to
challenge
the
browser
for
a
client
certificate.
The
login
method
for
the
plug-in
should
also
be
set
appropriately,
and
a
mapping
rule
should
be
created
in
the
usermap.conf
configuration
file
to
map
the
distinguished
name
in
the
certificate
to
a
Tivoli
Access
Manager
user.
For
more
information
about
the
user
mapping
file,
see
“User
mapping
configuration
file
(usermap.conf)”
on
page
16.
20
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Configuring
tag-value
pair
support
The
plug-in
supports
a
feature
where
user
information
is
extracted
from
LDAP
and
placed
into
the
user’s
credentials
after
authentication.
User
information
is
extracted
from
the
object
represented
by
the
user’s
LDAP
distinguished
name
and
can
optionally
be
added
to
the
HTTP
headers
for
the
backend
server.
The
following
example
illustrates
the
use
of
these
configuration
parameters:
[Remote:
/ESproxy/reverse/newbooks.com]
domains
=
newbooks.com
route
=
http://backend1.com
#
LDAP
attributes
to
be
extracted
into
user
credentials
tagvalue_creds_registry
=
lastname:sn
email:mail
tagvalue_creds_registry
=
account:internationalISDNNumber
#
Tag-Value
HTTP
headers
for
backend
server
tagvalue_creds_headers
=
lastname:X-LastName
email:X-Email
tagvalue_creds_headers
=
account:X-Account
#
To
place
all
tag-value
credentials
into
HTTP
headers
using
the
#
credential
attribute
name
as
the
HTTP
header
name,
use
this
setting
instead
#
tagvalue_creds_headers
=
*
Consider
the
scenario
where
the
inetOrgPerson
object
representing
the
user’s
distinguished
name
contains
the
following
attributes
in
LDAP:
cn=joe,
c=us
uid:
Joe
sn:
Smith
mail:
internationalISDNNumber:
123456789
987654321
The
following
attributes
are
added
to
the
user’s
credentials.
The
tagvalue_
prefix
differentiates
these
attributes
from
other
attributes:
tagvalue_lastname:
Smith
tagvalue_email:
tagvalue_account:
123456789
987654321
The
backend
server
receives
the
following
additional
information
in
the
HTTP
header:
X-LastName:
Smith
X-Email:
X-Account:
123456789::987654321
In
summary,
the
tagvalue_creds_registry
setting
extracts
user
information
from
LDAP
and
stores
it
in
the
user’s
credentials
after
the
user
is
authenticated.
Information
stored
in
the
user’s
credentials
can
be
added
to
the
HTTP
headers
destined
for
the
backend
server
using
the
tagvalue_creds_headers
setting,
ensuring
that
only
the
appropriate
headers
are
sent
to
each
backend
server.
Chapter
3.
Administering
the
plug-in
for
Edge
Server
21
22
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Chapter
4.
Understanding
the
plug-in
for
Edge
Server
configuration
This
chapter
provides
an
overview
of
the
plug-in
for
Edge
Server
configuration
explaining
concepts,
models,
and
procedures.
This
chapter
contains
the
following
sections:
v
“Server
configuration
model”
v
“Server
configuration
concepts
applied”
on
page
24
v
“Object
space
configuration
model”
on
page
26
v
“Single
signon
configuration
model”
on
page
28
v
“Configuration
procedure
summarized”
on
page
28
Server
configuration
model
The
plug-in
for
Edge
Server
provides
authentication
and
authorization
services
for
Web
servers
within
a
secured
domain
by
enforcing
the
security
at
the
Edge
Server
proxy,
rather
than
at
the
Web
server.
By
implementing
the
security
enforcement
at
the
proxy,
the
plug-in
centrally
provides
security
services
for
all
Web
servers
within
the
secured
domain.
One
the
Edge
Server
plug-in
has
established
that
a
particular
user
is
authorized
to
access
a
requested
resource,
the
request
is
forwarded
to
the
Web
server
along
with
the
user’s
information.
The
content
of
a
Web
site
might
span
multiple
Web
servers
for
reasons
of
performance
and
content
distribution.
While
some
Web
servers
might
host
content,
others
might
host
a
variety
of
Web
applications,
each
with
different
security
requirements.
For
example,
some
servers
might
not
require
authentication,
but
other
servers
might
require
it.
Each
server
requiring
authentication
might
require
the
user
information
be
submitted
in
a
unique
format.
While
some
security
settings
are
common
to
all
servers
such
as
form
session
timeout
and
logging
level,
some
are
unique
to
each
server
such
as
login
method
and
single
signon.
Because
of
this
distributed
nature,
the
plug-in
needs
to
be
able
to
provide
security
services
for
multiple
Web
servers
within
a
secure
domain.
The
plug-in
secures
distributed
Web
servers
using
the
’object
space
definition’
configuration
file,
osdef.conf.
This
configuration
file
separates
the
configuration
settings
for
each
protected
Web
server
so
that
Web
server
specific
configuration
is
possible.
There
are
three
types
of
server
definitions
used
in
the
configuration
file
as
shown
in
the
following
table.
Server
definition
Description
[Global]
Settings
listed
under
this
stanza
apply
to
all
Web
servers.
There
is
only
one
instance
of
this
stanza.
[Local]
Settings
listed
under
the
[Local]
stanza
apply
only
to
the
Edge
Server
caching
proxy.
There
is
only
one
instance
of
this
stanza.
[Remote:
Tivoli
Access
Manager
Object
Space
Name]
Settings
listed
under
the
[Remote:
...]
stanza
apply
to
external
or
remote
Web
servers
secured
by
the
plug-in.
There
can
be
multiple
instances
of
this
stanza.
©
Copyright
IBM
Corp.
2001,
2003
23
With
a
few
exceptions
that
are
documented
in
the
osdef.conf
file,
any
setting
can
be
placed
under
any
definition.
For
example,
the
form_session_timeout
setting,
can
be
placed
beneath
the
[Global]
stanza,
or
beneath
a
[Remote]
stanza
as
shown:
[Global]
login_method
=
forms
form_login_file
=
/opt/pdweb-lite/samples/forms/welcome.html
form_session_timeout
=
10
[Remote:
/ESproxy/reverse/anyother.com]
domains
=
anyother.com
[Remote:
/ESproxy/reverse/verysecure.com]
domains
=
verysecure.com
form_session_timeout
=
1
In
the
above
example,
any
user
who
logs
into
verysecure.com
is
not
allowed
to
remain
idle
for
more
than
one
minute,
otherwise
their
session
expires.
However,
for
any
user
who
logs
into
anyother.com
and
all
other
domains,
the
idle
timeout
is
10
minutes
due
to
it
being
set
in
the
[Global]
definition.
With
a
few
exceptions
([SSO]
settings),
this
model
of
inheritance
can
be
used
on
any
server
setting
in
the
configuration
file,
as
illustrated
in
Figure
5.
Using
this
model
of
inheritance,
settings
that
are
the
same
for
each
Web
server
do
not
need
to
be
repeated
under
each
server
definition
but
can
be
listed
once
underneath
the
[Global]
definition
of
the
configuration
file.
For
example,
if
all
servers
uses
the
same
form
login
file,
then
that
setting
can
be
listed
in
the
[Global]
definition.
Server
configuration
concepts
applied
With
a
basic
understanding
of
the
configuration
file,
it
is
easier
to
understand
how
the
plug-in
enforces
security
using
this
configuration
file.
Whenever
a
request
is
received
by
the
plug-in,
it
follows
the
following
basic
steps
to
authorize
the
user.
1.
If
the
user
is
already
authenticated,
for
example,
by
a
trusted
gateway,
accept
the
user
single
signon
information
and
proceed
to
step
4.
2.
Obtain
the
user
identity
based
on
one
of
the
following
login
methods:
v
For
basic
authentication
and
forms
login,
obtain
the
user
ID
and
password.
v
For
certificate
login,
obtain
the
certificate
distinguished
name.3.
Authenticate
the
user
against
the
Tivoli
Access
Manager
user
registry.
4.
Authorize
the
user
against
the
Tivoli
Access
Manager
object
space.
5.
Submit
single
signon
information
for
the
user.
[Global]
[Local] [Remote 1]
Internal Tivoli Access
Default Values
[Remote N]
Manager Plug-in
Figure
5.
Plug-in
for
Edge
Server
using
model
of
inheritance
24
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
6.
Forward
the
request
to
the
corresponding
Web
server.
To
execute
these
authorization
steps,
the
plug-in
must
consult
the
configuration
file
for
configuration
information
about
the
request.
Each
step
requires
one
or
more
settings
to
be
retrieved
from
the
osdef.conf
configuration
file.
For
example,
step
2
on
page
24
requires
the
retrieval
of
the
login_method
setting.
To
retrieve
a
setting
for
the
request,
the
plug-in
needs
to
first
determine
which
definition
it
should
retrieve
the
setting
from.
It
needs
to
correlate
the
request
with
a
specific
server
definition
in
the
configuration
file.
While
the
plug-in
can
enforce
security
for
both
reverse
and
forward
proxy
requests,
the
plug-in
does
not
consider
whether
the
request
is
a
reverse
or
forward
proxy
request.
The
domain
name
is
the
public
identifier
for
the
corresponding
Web
server
hosting
the
protected
resource.
In
a
reverse
proxy
scenario,
this
requires
the
creation
of
aliases
or
public
domain
names
on
the
plug-in
system,
as
illustrated
in
Figure
6.
In
this
configuration,
all
requests
for
www.newbooks.com,
newbooks.com,
newnovels.com,
and
newpoems.com
arrive
at
the
Edge
Server
proxy
and
are
secured
by
the
plug-in.
Using
the
domain
name
as
the
unique
identifier
for
the
request,
the
plug-in
can
now
search
the
configuration
file
for
the
server
definition
that
matches
the
domain
name.
Consider
the
following
osdef.conf
configuration
file:
[Global]
login_method
=
basic
#
Definition
1
[Remote:
/ESproxy/reverse/newbooks.com]
domains
=
newbooks.com
*.newbooks.com
login_method
=
forms
route
=
http://backend1.com
#
Definition
2
[Remote:
/ESproxy/reverse/label2]
domains
=
newnovels.com
login_method
=
certificate
route
=
http://backend2.com
#
Definition
3
[Remote:
/ESproxy/check_here/this_is_just_a_label]
domains
=
newpoems.com
route
=
http://backend3.com
Browser
Internal Gateway
backend2..comHosts newnovels.com
backend3.comHosts newpoems.com
Internet
BrowserEdge Server
newbooks.com
CachingProxy
Tivoli Access ManagerPlug-in
backend1.comHosts www.newbooks.comand newbooks.com
Web Servers
www.newbooks.com
newpoems.comnewnovels.com
Figure
6.
Creation
of
aliases
on
a
plug-in
system
Chapter
4.
Understanding
the
plug-in
for
Edge
Server
configuration
25
Consider
the
following
requests
where
the
plug-in
determines
the
login
method,
object
space
location
where
the
user
is
authorized,
and
destination
Web
server
where
the
request
is
forwarded:
v
If
a
user
types
the
following
URL,
the
plug-in
matches
the
request
to
definition
1
because
the
domains
setting
contains
the
value,
*.newbooks.com:
http://www.newbooks.com/private.html
The
login
method
is
forms
because
it
is
explicitly
set
under
this
definition.
For
the
authorization
check,
the
domain
name
would
be
replaced
with
the
authorization
string
and
the
URL
path
would
be
appended.
In
this
example,
the
authorization
check
for
read
(r)
permission
would
be
performed
at
/ESproxy/reverse/newbooks.com/private.html.
The
request
is
forwarded
to
backend1.com
because
of
the
route
setting.
v
If
a
user
types
the
following
URL,
the
plug-in
first
performs
a
reverse
DNS
lookup
on
the
IP
address
and
would
match
the
request
to
definition
2
because
the
domains
setting
contains
the
value,
newnovels.com:
http://IP_address_of_newnovels.com/gifs/private.html
The
login
method
is
certificate
because
it
is
explicitly
set
under
this
definition.
The
authorization
check
for
read
(r)
permission
is
performed
at
/ESproxy/reverse/label2/gifs/private.html.
The
request
is
forwarded
to
backend2.com
because
of
the
route
setting.
v
If
a
user
types
the
following
URL,
the
plug-in
would
match
the
request
to
definition
3
because
the
domains
setting
contains
the
value,
newpoems.com:
http://newpoems.com/logo.gif
The
login
method
is
basic
because
it
is
not
explicitly
set
under
this
definition
and
is
retrieved
from
the
[Global]
definition.
The
authorization
check
for
read
(r)
permission
is
performed
at
/ESproxy/check_here/this_is_just_a_label
/logo.gif.
The
request
is
forwarded
to
backend3.com
due
to
the
route
setting.
v
If
a
user
configures
their
browser
to
use
Edge
Server
as
a
proxy
and
types
the
following
URL,
the
plug-in
does
not
find
a
match
for
the
request
and
uses
the
[Global]
definition:
http://internet.com/mail/logo.gif
The
login
method
is
basic.
For
the
authorization
check,
the
default
forward
proxy
template,
/ESproxy/forward/domain/path
is
used.
In
this
example,
the
authorization
check
for
read
(r)
permission
is
performed
at
/ESproxy/forward/internet.com/mail/logo.gif.
Since
this
object
might
not
exist
in
the
object
space,
the
effective
permission
is
inherited
from
the
ACL
attached
to
/ESproxy/forward.
The
request
is
automatically
forwarded
to
internet.com
because
it
was
a
forward
proxy
request.
However,
it
is
possible
to
create
a
definition
in
the
configuration
file
that
performed
an
authorization
check
at
another
location
in
the
object
space
and
forwards
the
internet.com
request
elsewhere.
The
plug-in
does
not
consider
if
the
request
is
a
forward
or
reverse
proxy
request.
In
both
configurations,
the
request
is
handled
in
the
same
manner.
Object
space
configuration
model
When
the
plug-in
performs
an
authorization
check
underneath
a
branch
in
the
Tivoli
Access
Manager
object
space,
it
maps
the
requested
resource
or
URL
to
the
object
space.
For
example,
in
server
definition
1,
the
following
mapping
is
performed
for
the
authorization
check:
URL
Object:
http://www.newbooks.com/private.html
Tivoli
Access
Manager
Object:
/ESproxy/reverse/newbooks.com/private.html
26
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
In
order
to
apply
access
control
to
specific
objects
using
Tivoli
Access
Manager
ACLs,
the
object
space
must
be
structured
in
a
manner
where
there
is
a
direct
mapping
between
the
set
of
objects
that
users
request
in
their
URLs
and
the
set
of
objects
provided
by
the
Web
server.
The
simplest
case
is
a
direct
mapping
between
referenced
files
in
the
URLs
and
actual
files
on
the
Web
server,
as
illustrated:
Tivoli
Access
Manager
Object:
/ESproxy/reverse/newbooks.com/server
files
/ESproxy/reverse/newbooks.com/private.html
/ESproxy/reverse/newbooks.com/public.html
/ESproxy/reverse/newbooks.com/gifs
/ESproxy/reverse/newbooks.com/gifs/logo.gif
URL
Object:
http://www.newbooks.com/server
files
http://www.newbooks.com/private.html
http://www.newbooks.com/public.html
http://www.newbooks.com/gifs
http://www.newbooks.com/gifs/logo.gif
The
sample
query_contents
utility
provides
the
wesosm
utility
with
the
paths
of
all
files
on
the
Web
server.
The
file
information
is
copied
into
the
object
space
so
that
when
the
plug-in
performs
the
authorization
check,
there
is
a
direct
mapping
between
the
URL
objects
and
server
objects.
This
model
works
well
if
the
set
of
URL
objects
are
always
going
to
be
physical
files
on
the
destination
Web
server
that
the
query_contents
utility
finds.
In
some
cases,
the
set
of
URL
objects
might
not
correspond
directly
to
physical
files
on
the
Web
server.
In
this
case,
the
query_contents
utility
can
be
modified
to
return
the
virtual
objects
that
are
served
by
the
Web
server
as
shown:
Tivoli
Access
Manager
Object:
/ESproxy/reverse/newbooks.com/virtual
objects
/ESproxy/reverse/newbooks.com/object1
/ESproxy/reverse/newbooks.com/object2
/ESproxy/reverse/newbooks.com/object3
/ESproxy/reverse/newbooks.com/object3/object3.1
URL
Object:
http://www.newbooks.com/virtual
objects
http://www.newbooks.com/object1
http://www.newbooks.com/object2
http://www.newbooks.com/object3
http://www.newbooks.com/object3/object3.1
In
this
scenario,
the
objects
served
by
the
Web
server
do
not
correspond
directly
to
physical
files
on
the
Web
server.
However,
the
Web
server
understands
what
these
objects
are
and
knows
how
to
retrieve
them.
As
long
as
the
query_contents
utility
can
enumerate
these
virtual
objects
for
the
wesosm
utility,
the
plug-in
can
perform
authorization
checks
on
these
virtual
objects.
The
plug-in
performs
authorization
checks
by
verifying
the
appropriate
permissions
in
the
Tivoli
Access
Manager
object
space.
It
maps
the
URL
to
the
object
space
to
determine
the
exact
location
to
perform
the
authorization
check.
In
order
to
apply
ACLs
on
specific
objects
secured
by
the
plug-in,
it
is
necessary
to
ensure
that
the
set
of
objects
represented
in
the
object
space
corresponds
to
the
set
of
objects
represented
in
the
URL
requests
for
the
secured
Web
server.
Chapter
4.
Understanding
the
plug-in
for
Edge
Server
configuration
27
Single
signon
configuration
model
The
plug-in
supports
customizable
single
signon
tokens
that
are
created
underneath
the
[SSO]
categories
of
the
object
space
definition
configuration
file
as
indicated
in
the
following
table.
Server
definition
Description
[SSO]
Settings
listed
under
this
definition
are
used
to
define
single
signon
tokens.
There
can
be
multiple
instances
of
this
definition.
The
settings
listed
in
this
definition
are
not
related
to
the
settings
listed
in
the
[Global],
[Local],
and
[Remote]
server
definitions.
For
example,
the
trust_list
setting,
is
not
valid
underneath
any
server
definition
in
the
configuration
file.
However,
by
defining
the
single
signon
tokens
in
one
place,
they
can
be
used
as
parameters
to
accept_sso
and
submit_sso,
which
are
valid
underneath
the
server
categories.
The
following
example
shows
the
definition
of
an
iv-user
token
which
is
needed
by
two
Web
servers:
[Remote:
/ESproxy/reverse/newbooks.com]
domains
=
newbooks.com
accept_sso
=
mysso
submit_sso
=
mysso
route
=
http://backend1.com
[Remote:
/ESproxy/reverse/newnovels.com]
domains
=
newnovels.com
submit_sso
=
mysso
route
=
http://backend2.com
[SSO:
mysso]
name
=
iv-user
format
=
<userid>
trust_basis
=
IP_Address
trust_list
=
0.0.0.0/0.0.0.0
In
this
example,
the
plug-in
checks
for
the
existence
of
the
iv-user
token
from
any
IP
address
that
makes
a
request
to
newbooks.com.
If
the
iv-user
token
is
found,
it
extracts
the
user
ID
from
the
token
and
authorizes
the
user.
The
plug-in
also
submits
the
iv-user
token
to
the
respective
backend
server
for
requests
to
newbooks.com
and
newnovels.com.
Configuration
procedure
summarized
The
plug-in
for
Edge
Server
provides
a
flexible
framework
to
configure
access
control
to
the
protected
resources
on
your
Web
servers.
It
allows
you
to
set
server
specific
configuration
items
such
as
the
login
method,
single
signon
token,
and
destination
server.
Settings
that
apply
to
each
server
need
to
only
be
set
in
one
place
and
settings
that
are
server
specific
can
be
set
for
each
respective
server.
The
general
approach
to
configuring
the
plug-in
is
as
follows:
1.
For
a
reverse
proxy
configuration,
create
an
alias
domain
name
on
the
plug-in
machine
for
each
Web
server
that
requires
the
authorization
services.
2.
Create
a
corresponding
[Remote]
server
definition
for
each
respective
server
and
assign
the
alias
domain
name
to
that
definition.
3.
Set
server
specific
settings
underneath
the
definition
for
that
server
and
set
global
settings
in
the
[Global]
definition
of
the
configuration
file.
It
is
sufficient
to
use
the
default
internal
plug-in
values
for
most
settings.
28
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
4.
Run
the
wesosm
utility
to
generate
the
object
space
and
set
the
appropriate
ACLs
in
the
Tivoli
Access
Manager
object
space
for
access
control
to
that
server.
Always
restart
the
plug-in
after
making
configuration
changes.
If
you
are
unable
to
determine
the
cause
of
a
configuration
error,
check
the
event
log
file
for
information
describing
how
the
plug-in
handled
the
request.
Running
the
UNIX
tail
-f
command
on
the
event
log
file
can
help
in
observing
events
as
they
happen
in
real
time.
It
is
easier
to
determine
the
cause
of
the
configuration
problem
after
observing
the
event
log.
Chapter
4.
Understanding
the
plug-in
for
Edge
Server
configuration
29
30
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Chapter
5.
An
example
plug-in
for
Edge
Server
deployment
This
chapter
describes
an
example
deployment
for
the
IBM
Tivoli
Access
Manager
Plug-in
for
Edge
Server.
This
deployment
shows
an
example
of
a
commercial
Web
site
where
visitor
access
must
be
controlled.
The
example
is
described
in
the
following
sections:
v
“Designing
the
Web
site”
on
page
31
v
“Configuring
the
Web
site”
on
page
32
Designing
the
Web
site
In
this
section,
a
complete
plug-in
for
Edge
Server
configuration
for
newbooks.com
is
designed.
This
Web
site
allows
users
to
browse
and
purchase
books.
Many
of
the
key
features
of
the
plug-in
for
Edge
Server
are
illustrated
in
this
example.
The
Web
site
design
is
divided
into
the
following
components:
v
“Content
distribution”
on
page
31
v
“Single
signon”
on
page
31
Content
distribution
In
this
design,
rather
than
storing
the
entire
content
for
the
Web
site
on
one
Web
server,
it
is
distributed
across
several
Web
servers.
The
Web
content
is
divided
into
the
following
sections:
v
newbooks.com
v
catalog.newbooks.com
v
account.newbooks.com
v
payment.newbooks.com
The
newbooks.com
domain
contains
the
greeting
page
and
links
to
other
parts
of
the
Web
site.
The
catalog.newbooks.com
subdomain
contains
a
repository
of
all
the
books
sold
at
this
Web
site.
These
sections
of
the
Web
site
do
not
require
access
control
and
therefore
are
not
protected.
The
account.newbooks.com
directory
contains
HTML
and
Java
code
that
is
used
to
manage
the
user’s
account.
The
payment.newbooks.com
directory
also
contains
HTML
and
Java
code
to
receive
the
user’s
payment
for
books
to
be
purchased.
Most
of
these
sections
of
the
Web
site
are
protected.
A
directory
underneath
account.newbooks.com
is
used
to
register
new
users.
This
directory
is
not
protected.
Single
signon
In
this
design,
an
application
running
on
the
Web
server
hosting
the
account.newbooks.com
subdomain
requires
an
encrypted
Lightweight
Third
Party
Authentication
(LTPA)
cookie
to
identify
the
authenticated
user.
Another
application
running
on
the
Web
server
hosting
the
payment.newbooks.com
subdomain
requires
the
HTTP
header,
App-User,
with
the
user
ID
in
it.
It
also
requires
basic
authentication
from
the
plug-in
for
Edge
Server
as
the
trust
basis
for
accepting
the
authenticated
user.
The
plug-in
for
Edge
Server
is
required
to
authenticate
itself
to
this
application
with
the
user
ID,
plugin,
and
the
password,
bookworm.
©
Copyright
IBM
Corp.
2001,
2003
31
In
this
example,
a
relationship
has
been
established
with
another
vendor,
newnovels.com,
to
forward
authenticated
users
through
the
plug-in
for
Edge
Server
to
protected
areas
of
newbooks.com.
The
gateway
at
newnovels.com
is
required
to
authenticate
itself
to
the
plug-in
for
Edge
Server
by
using
an
authorization
header
with
the
user
ID,
novelgateway,
and
the
password,
bookworm.
The
gateway
places
the
authenticated
user
ID
in
the
cookie
Novel-User,
as
illustrated
in
Figure
7.
Configuring
the
Web
site
To
provide
access
control
for
newbooks.com,
the
plug-in
for
Edge
Server
must
be
configured.
The
configuration
begins
by
defining
the
global
settings
in
the
osdef.conf
configuration
file
as
shown
in
the
following
example:
[Global]
#
Administrator
userid
and
password
needed
to
run
wesosm
update_admin_userid
=
sec_master
update_admin_password
=
secret5
#
Error
message
indicating
that
SSL
is
required
require_ssl_errorfile
=
/opt/pdweb-lite/samples/errorpages/require_ssl.htmls
#
Form
login
and
logout
information
login_method
=
forms
form_login_file
=
http://newbooks.com/pub/login.html
form_login_errorfile
=
http://newbooks.com/pub/loginerr.html
form_logout_url
=
/pub/logout.html
#
Change
password
information
form_chgpasswd_file
=
http://newbooks.com/pub/chgpasswd.html
form_chgpasswd_submit_url
=
/pub/chgpasswd
form_chgpasswd_response_url
=
/pub/passwdchanged.html
#
Single
signon
tokens
to
look
for
accept_sso
=
NovelSSO
The
[Global]
definition
in
the
configuration
file
specifies
settings
that
apply
to
every
request
handled
by
the
plug-in
for
Edge
Server.
In
this
configuration,
the
administrator
user
ID
and
password
is
provided
so
that
the
wesosm
utility
can
create
and
update
the
object
space.
Also,
if
a
request
requires
a
secure
connection
and
one
is
not
provided,
the
specified
error
page
is
returned
to
the
user.
However,
if
possible,
the
browser
is
automatically
redirected
to
the
secure
site.
Browser
Internal Gateway
backend2.newbooks.comHosts account.newbooks.com
backend3.newbooks.comHosts payment.newbooks.com
Internet
Browser
Gateway
newnovels.com Novel-User
Edge Servernewbooks.com
CachingProxy
Tivoli AccessManager Plug-in
App-User
LTPA
Cookie
backend1.newbooks.comHosts newbooks.com and
catalog.newbooks.com
Web Servers
Figure
7.
Web
site
design
for
newbooks.com
32
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
This
configuration
also
specifies
the
login
method
as
forms
and
lists
the
login
forms.
The
login
forms
can
be
retrieved
from
a
remote
Web
server
(begins
with
http)
or
can
be
retrieved
from
the
local
file
system.
If
the
form
has
references
to
images
in
it,
the
URL
links
in
the
forms
for
these
images
should
contain
the
full
URL
of
the
images,
such
as
the
following:
http://newbooks.com/pub/gifs/banner.gif
The
user
is
logged
out
when
the
requested
path
of
the
URL
matches
the
path
specified
for
the
logout
URL.
Also,
as
the
configuration
shows,
a
change
password
form
is
sent
to
authenticated
users
when
their
passwords
expire.
Single
signon
users
are
accepted
from
the
gateway
at
newnovels.com,
using
the
NovelSSO
single
signon
definition.
This
single
signon
definition
must
be
defined
in
the
configuration
file.
The
[Local]
definition
in
the
configuration
file
specifies
settings
that
apply
to
objects
on
the
file
system
managed
by
the
Edge
Server
caching
proxy.
There
should
only
be
one
of
these
definitions
in
the
configuration
file.
This
server
definition
was
created
by
the
configuration
tool
and
is
similar
to
the
following:
[Local:
/ESproxy/bookproxy.com]
domains
=
bookproxy.com
query_command
=
http://bookproxy.com/cgi-bin/query_contents?dirlist=/
login_method
=
basic
In
this
example,
bookproxy.com
is
the
primary
domain
name
of
the
machine
that
the
Edge
Server
caching
proxy
is
running
on.
The
alias
newbooks.com
is
another
domain
name
(with
its
associated
IP
address)
assigned
to
the
same
machine.
The
plug-in
for
Edge
Server
differentiates
between
requests
for
objects
belonging
to
the
Edge
Server
caching
proxy
and
objects
belonging
to
newbooks.com
by
matching
the
requested
domain
name
with
a
server
definition
in
the
configuration
file.
The
domains
setting
indicates
the
domains
to
which
a
server
definition
applies.
The
[Remote]
definitions
in
the
configuration
file
specify
settings
that
apply
to
external
Web
servers.
There
is
no
limit
on
the
number
of
server
definitions
that
you
can
have.
For
this
example,
the
following
definition
would
be
appropriate
for
newbooks.com:
[Remote:
/ESproxy/reverse/newbooks.com]
domains
=
newbooks.com
www.newbooks.com
#
Query
command
to
create
object
space
query_command
=
http://backend1.newbooks.com/cgi-bin/query_contents?dirlist=/home
#
Server
to
map
requests
route
=
http://backend1.newbooks.com/home
The
following
subdomain
definitions
are
defined
for
the
other
sections
of
the
Web
site:
[Remote:
/ESproxy/reverse/catalog.newbooks.com]
domains
=
catalog.newbooks.com
query_command
=
http://backend1.newbooks.com/cgi-bin/query_contents?dirlist=/catalog
route
=
http://backend1.newbooks.com/catalog
[Remote:
/ESproxy/reverse/account.newbooks.com]
domains
=
account.newbooks.com
query_command
=
http://backend2.newbooks.com/cgi-bin/query_contents?dirlist=/
require_ssl
=
yes
submit_sso
=
LTPA-COOKIE
route
=
https://backend2.newbooks.com
Chapter
5.
An
example
plug-in
for
Edge
Server
deployment
33
[Remote:
/ESproxy/reverse/payment.newbooks.com]
domains
=
payment.newbooks.com
query_command
=
http://backend3.newbooks.com/cgi-bin/query_contents?dirlist=/
require_ssl
=
yes
submit_sso
=
PayAppSSO
PayAppAuth
route
=
https://backend3.newbooks.com
These
server
definitions
specify
the
single
signon
tokens
to
submit
to
each
Web
server
that
requires
one.
The
definitions
also
tell
the
plug-in
for
Edge
Server
to
map
the
URL
to
the
corresponding
Web
server
hosting
the
requested
content.
If
another
routing
module
is
to
be
used
in
place
of
the
plug-in
for
Edge
Server
URL
mapping,
simply
delete
all
references
to
the
route
keyword
from
the
configuration
file.
The
[SSO]
definitions
in
the
configuration
file
define
single
signon
tokens
that
can
either
be
accepted
or
submitted
as
shown:
[SSO:
PayAppSSO]
type
=
header
name
=
App-User
format
=
“<userid>”
[SSO:
PayAppAuth]
type
=
auth_header
format
=
plugin:bookworm
[SSO:
NovelSSO]
type
=
cookie
name
=
Novel-User
format
=
“<userid>”
trust_basis
=
basic_auth
trust_list
=
novelgateway:bookworm
After
you
create
single
signon
definitions,
they
can
be
supplied
as
options
to
the
accept_sso
and
submit_sso
keywords.
Single
signon
requirements
in
this
example
are
now
satisfied.
34
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Chapter
6.
Creating
a
Cross-domain
Authentication
Service
This
chapter
explains
how
to
create
a
Cross-domain
Authentication
Service
(CDAS)
shared
library,
which
enables
custom
handling
and
processing
of
client
authentication
information.
It
also
describes
how
to
configure
the
plug-in
for
Edge
Server
to
use
the
custom
shared
library
for
authentication.
A
demonstration
CDAS
library
is
packaged
with
the
plug-in
for
Edge
Server
that
illustrates
the
implementation
of
the
CDAS
functions.
You
can
recompile
and
modify
this
demonstration
library
to
create
a
custom
shared
library.
This
chapter
includes
the
following
sections:
v
“Authentication
models”
v
“Building
a
custom
shared
library”
on
page
38
v
“Configuring
the
plug-in
for
Edge
Server
to
use
a
custom
shared
library”
on
page
41
v
“CDAS
core
and
utility
functions”
on
page
44
v
“CDAS
API
core
function
reference”
on
page
44
Authentication
models
This
section
describes
two
types
of
CDAS
authentication
models:
v
“Single
authentication
model”
on
page
35
v
“Dispatched
authentication
model”
on
page
36
When
IBM
Tivoli
Access
Manager
plug-in
for
Edge
Server
receives
a
client
request,
it
passes
the
appropriate
authentication
data
to
the
custom
shared
library.
Rather
than
authenticating
the
user
against
the
Tivoli
Access
Manager
user
registry,
the
CDAS
shared
library
authenticates
the
user
against
an
alternate
user
registry
using
an
external
authentication
mechanism.
Ultimately,
the
CDAS
returns
a
Tivoli
Access
Manager
identity
to
the
plug-in
for
authorization
against
the
Tivoli
Access
Manager
object
space.
If
you
create
a
custom
CDAS
shared
library
to
handle
user
name
and
password
authentication,
the
client
authentication
data
must
contain
the
user’s
name
and
password.
However,
if
the
shared
library
is
written
to
handle
certificate
authentication,
the
client
authentication
data
must
contain
the
client’s
certificate.
Single
authentication
model
Figure
8
on
page
36
illustrates
an
example
of
single
authentication
CDAS
functionality.
©
Copyright
IBM
Corp.
2001,
2003
35
Steps
illustrated
in
Figure
8
are
as
follows:
1.
The
client
supplies
authentication
information
to
the
plug-in.
2.
In
this
example,
the
plug-in
is
configured
to
use
a
custom
CDAS
shared
library
for
authentication.
The
CDAS
shared
library
could
authenticate
this
user
internally
and
pass
the
resulting
Tivoli
Access
Manager
identity
back
to
the
plug-in
(step
4).
For
example,
the
shared
library
could
accept
a
digital
certificate,
modify
the
Distinguished
Name
(DN)
data,
and
return
the
modified
DN
as
the
Tivoli
Access
Manager
identity.
3.
The
custom
shared
library
could
instead
send
the
data
to
an
external
authentication
service
that
performs
its
own
authentication
of
the
client,
perhaps
using
a
third-party
(legacy)
user
registry.
4.
The
CDAS
returns
one
of
the
following
status
codes
to
the
plug-in:
v
A
successful
status
code
(indicating
a
successful
authentication
attempt)
and
a
Tivoli
Access
Manager
identity.
v
An
unsuccessful
status
code,
indicating
a
failed
authentication
attempt.
In
addition,
the
custom
CDAS
can
be
written
to
provide
extended
attribute
data
to
the
plug-in
(for
inclusion
in
the
user
credential).
5.
If
a
successful
status
code
is
returned,
the
plug-in
tries
to
match
the
identity
with
an
entry
in
the
Tivoli
Access
Manager
user
registry.
If
a
match
is
found,
the
plug-in
treats
the
client
as
authenticated.
Otherwise,
it
treats
the
client
as
unauthorized.
A
successful
authentication
results
in
a
Tivoli
Access
Manager
credential
for
the
user.
Any
extended
attribute
data
is
included
in
the
credential
and
can
be
extracted
later
for
appropriate
use.
The
credential
enables
the
user
to
participate
in
the
Tivoli
Access
Manager
secure
domain.
Dispatched
authentication
model
You
can
create
a
CDAS
module
that
dispatches
authentication
requests
to
other
CDAS
modules
based
on
a
correlating
parameter
passed
in
from
the
plug-in.
The
dispatching
CDAS
module
does
not
perform
any
authentication
itself,
but
delegates
the
authentication
and
creation
of
extended
attributes
to
the
other
CDAS
modules
and
passes
the
returned
identity
from
the
CDAS
modules
back
to
the
plug-in.
Using
this
model,
the
plug-in
can
authenticate
against
different
user
registries,
based
on
the
URL.
Client
ResourceManager
ExternalAuthentication
Service
authentication
information
identity
1
Edge Server Plug-in
Custom CDAS SharedLibrary
authn
info
2
3
4
UserRegistry
ExternalRegistry
5
Figure
8.
Example
CDAS
authentication
model
36
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Figure
9
illustrates
an
example
of
the
CDAS
dispatched
functionality.
Steps
illustrated
in
Figure
9
are
as
follows:
1.
The
client
supplies
authentication
information
to
the
plug-in.
2.
In
this
example,
the
plug-in
is
configured
to
use
a
custom
CDAS
shared
library
to
handle
this
type
of
authenticated
data.
3.
Based
on
a
parameter
passed
in
from
the
plug-in,
the
CDAS
module
dispatches
the
authentication
to
the
appropriate
CDAS
module
for
the
request.
The
CDAS
shared
library
could
authenticate
this
user
internally
and
pass
the
resulting
Tivoli
Access
Manager
identity
back
to
the
CDAS
dispatcher.
For
example,
the
shared
library
could
accept
a
digital
certificate,
modify
the
Distinguished
Name
(DN)
data,
and
return
the
modified
DN
as
the
Tivoli
Access
Manager
identity.
4.
The
custom
shared
library
could
instead
send
the
data
to
an
external
authentication
service
that
performs
its
own
authentication
of
the
client,
perhaps
using
a
third-party
(legacy)
user
registry.
5.
The
appropriate
CDAS
module
returns
the
Tivoli
Access
Manager
identity
and
extended
attributes
to
the
CDAS
dispatcher.
6.
The
CDAS
dispatcher
module
returns
one
of
the
following
status
codes
to
the
plug-in:
v
A
successful
status
code
(indicating
a
successful
authentication
attempt)
and
a
Tivoli
Access
Manager
identity.
v
An
unsuccessful
status
code,
indicating
a
failed
authentication
attempt.
In
addition,
the
custom
CDAS
can
be
written
to
provide
extended
attribute
data
to
the
plug-in
(for
inclusion
in
the
user
credential).
7.
If
a
successful
status
code
is
returned,
the
plug-in
tries
to
match
the
identity
with
an
entry
in
the
Tivoli
Access
Manager
user
registry.
If
a
match
is
found,
the
plug-in
treats
the
client
as
authenticated.
Otherwise,
it
treats
the
client
as
unauthorized.
Client
authentication
information
1
Edge Server Plug-in
3
ResourceManager
authninfo
2
4External
AuthenticationService
ExternalRegistry
UserRegistry
5CDAS
Dispatcher
Custom CDASShared Library
identity
6
7
Custom CDASShared Library
Figure
9.
Example
dispatched
authentication
model
Chapter
6.
Creating
a
Cross-domain
Authentication
Service
37
Building
a
custom
shared
library
Before
you
build
a
custom
CDAS
library,
you
must
determine
how
you
want
the
specific
authentication
and
mapping
service
to
operate
in
your
secure
domain.
Use
the
resources
of
the
demonstration
CDAS
to
implement
your
custom
CDAS
library.
This
section
contains
the
following
topics:
v
“CDAS
application
development
kit”
v
“Programming
the
custom
shared
library”
v
“User
authentication
data”
on
page
39
v
“Returning
the
client
identity”
on
page
40
v
“Compiling
the
custom
shared
library”
on
page
40
CDAS
application
development
kit
The
CDAS
application
development
kit
(ADK)
includes
the
following
components:
v
API
library
(utility
functions)
v
API
header
files
v
Example
CDAS
source
file
(for
demonstration
only)
v
Makefile
The
CDAS
ADK
files
are
located
in
one
of
the
following
directories:
v
On
UNIX
systems:
/opt/pdweb-lite/samples/cdas_adk
v
On
Windows
systems:
install_dir\samples\cdas_adk
The
ADK
components
are
contained
in
the
following
subdirectories.
Directory
Contents
include
This
directory
contains
the
C
header
file,
espi_xauthn.h,
which
defines
the
parmeters:
xauthn_extended_handle
and
xauthn_extended_parameter,
and
includes
pdxauthn.h.
example
The
example
directory
contains:
-
Source
file
(xauthn.c)
-
Makefile
-
A
pre-built
platform-specific
example
shared
library
to
demonstrate
a
functional
CDAS
Programming
the
custom
shared
library
A
custom
CDAS
shared
library
must
contain
the
following
APIs:
v
xauthn_initialize
For
more
information,
see
“Initialization:
xauthn_initialize”
on
page
39
v
xauthn_shutdown
For
more
information,
see
“Shutdown:
xauthn_shutdown”
on
page
39
v
xauthn_authenticate
For
more
information,
see
“Authentication:
xauthn_authenticate”
on
page
39
v
xauthn_change_password
38
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
For
more
information,
see
“Password
change:
xauthn_change_password”
on
page
39
Note:
These
API
functions
are
described
in
detail
in
the
“CDAS
API
core
function
reference”
on
page
44.
Initialization:
xauthn_initialize
The
plug-in
loads
the
CDAS
shared
library
and
initializes
it
by
calling
xauthn_initialize.
This
function
contains
the
argc
and
argv
options.
These
options
contain
the
values
specified
in
the
osdef.conf
configuration
file.
Unlike
the
C
language
argv,
the
argv[0]
array
entry
is
the
first
option.
Shutdown:
xauthn_shutdown
During
shutdown,
the
plug-in
calls
the
xauthn_shutdown
function
to
stop
the
CDAS
shared
library
process.
The
xauthn_shutdown
function
is
called
with
the
same
argc
and
argv
options
that
were
passed
to
the
xauthn_initialize
function
when
the
shared
library
was
first
initialized.
Authentication:
xauthn_authenticate
After
the
CDAS
shared
library
is
configured
and
a
request
is
received,
the
plug-in
passes
the
user’s
information
to
the
shared
library
through
the
xauthn_authenticate
function.
User
authentication
information
is
passed
to
this
function
in
a
name/value
data
list
(xnvlist_t).
The
content
of
the
name/value
data
list
can
vary
and
is
specific
to
the
configured
authentication
method.
The
xauthn_authenticate
function
performs
the
application-specific
authentication
process
based
on
the
authentication
information
found
in
the
data
list
and
returns
the
resulting
client
identity
(xauthn_identity_t)
to
the
plug-in.
It
is
important
to
note
that
the
client
identity
returned
through
this
function
can
contain
extended
attribute
data.
Password
change:
xauthn_change_password
This
function
allows
the
user
to
make
changes
to
the
account
password
that
is
stored
in
the
alternate
user
registry.
Only
the
user
name
and
password
authentication
method
supports
this
function.
If
the
external
authentication
mechanism
does
not
support
password
changes,
this
function
returns:
XAUTHN_S_UNSUPPORTED_AUTHN_METHOD
User
authentication
information
is
passed
to
this
function
in
a
name/value
data
list
(xnvlist_t).
The
data
list
contains
the
user’s
name,
the
old
password,
and
the
new
password.
User
authentication
data
The
plug-in
can
pass
a
variety
of
client
authentication
information
to
the
shared
library.
The
information
is
passed
using
a
name/value
list
format,
where
the
name
is
an
identifier
that
specifies
the
value
type.
The
information
is
stored
in
the
xnvlist_t
data
type.
Values
can
be
accessed
by
using
the
utility
function
xnvlist_get.
Chapter
6.
Creating
a
Cross-domain
Authentication
Service
39
The
following
table
lists
the
user
authentication
options
that
the
plug-in
passes
to
the
CDAS
module.
Authentication
method
Name
Value
User
name/Password
xauthn_username
xauthn_password
xauthn_new_password
xauthn_ipaddr
xauthn_browser_info
xauthn_extended_handle
xauthn_extended_parameter
-
User
name
-
User
password
-
User
new
password
-
User
IP
address
-
Browser
information
-
Caching
proxy
handle
-
Configuration
file
option
Certificate
xauthn_cert_dn
xauthn_ipaddr
xauthn_browser_info
xauthn_extended_handle
xauthn_extended_parameter
-
Certificate’s
DN
-
User
IP
address
-
Browser
information
-
Caching
proxy
handle
-
Configuration
file
option
Single
signon
xauthn_ipaddr
xauthn_browser_info
″Request-URI″
″Request-Headers″
xauthn_extended_handle
xauthn_extended_parameter
-
User
IP
address
-
Browser
information
-
Request
URL
-
Request
Headers
-
Caching
proxy
handle
-
Configuration
file
option
While
the
CDAS
implementation
for
the
plug-in
for
Edge
Server
is
similar
to
WebSEAL,
there
are
minor
differences.
These
are
as
follows:
v
xauthn_extended_handle
and
xauthn_extended_parameter
are
options
that
the
plug-in
for
Edge
Server
passes
to
the
CDAS
module.
v
xauthn_extended_handle
provides
the
CDAS
module
with
the
caching
proxy’s
handle
necessary
to
extract
additional
HTTP
headers
using
the
caching
proxy’s
API.
v
xauthn_extended_parameter
provides
the
CDAS
module
with
a
correlating
option
from
the
osdef.conf
configuration
file.
Note:
The
parameters,
xauthn_extended_handle
and
xauthn_extended_parameter
are
defined
in
espi_xauthn.h.
Returning
the
client
identity
The
CDAS
shared
library
is
required
to
return
the
resulting
client
identity
back
to
the
plug-in.
The
client
identity
is
defined
by
the
xauthn_identity_t
data
structure.
For
more
information,
see
the
IBM
Tivoli
Access
Manager
WebSEAL
Developer’s
Guide.
Compiling
the
custom
shared
library
The
source
code
for
the
CDAS
demonstration
library
is
located
in
one
of
the
following
directories:
v
For
UNIX
systems:
/opt/pdweb-lite/samples/cdas_adk/example
v
For
Windows
systems:
install_dir\samples\cdas_adk\example
The
source
files
xauthn.c
and
xauthn.h
are
used
to
create
the
CDAS
shared
object.
40
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
To
customize
and
compile
the
custom
CDAS
shared
library,
do
the
following:
1.
Customize
the
source
files
to
implement
the
logic
necessary
to
authenticate
users
to
your
user
registry.
2.
To
recompile
the
code,
use
one
of
the
following
makefiles:
v
For
UNIX
systems:
/opt/pdweb-lite/samples/cdas_adk/example/Makefile.in
v
For
Windows
systems:
install_dir\samples\cdas_adk\example\Makefile.in
Instructions
for
compiling
on
each
platform
are
included
in
Makefile.in.
The
makefile
assumes
that
your
compiler
and
link
commands
can
be
invoked
from
the
current
directory
and
are
already
in
the
system’s
path.
3.
After
the
customized
CDAS
module
is
successfully
built,
the
resulting
shared
library
is
named
as
follows:
v
For
AIX
systems:
libwslcdas.a
v
For
Linux
systems:
libwslcdas.so
v
For
Solaris
systems:
libwslcdas.so
v
For
Windows
systems:
wslcdas.dll
4.
Stop
the
plug-in
and
copy
the
new
CDAS
module
over
the
existing
CDAS
module
that
is
located
in
one
of
the
following
directories:
v
For
UNIX
systems:
/opt/pdweb-lite/lib
v
For
Windows
systems:
install_dir\bin
Note:
For
more
information
on
starting
and
stopping
the
plug-in,
see
“Starting
and
stopping
the
plug-in
for
Edge
Server”
on
page
13.
Configuring
the
plug-in
for
Edge
Server
to
use
a
custom
shared
library
This
section
discusses
the
specific
configuration
steps
that
you
must
perform
so
that
the
plug-in
for
Edge
Server
can
use
the
CDAS
interface.
This
section
contains
the
following
topics:
v
“Configuring
a
custom
shared
library”
on
page
41
v
“Custom
shared
library
configuration
scenario”
v
“Configuring
the
demonstration
library”
on
page
42
v
“Loading
the
custom
shared
library”
on
page
43
Configuring
a
custom
shared
library
To
configure
a
custom
CDAS
shared
library,
modify
the
configuration
options
included
in
the
osdef.conf
file.
For
more
information
about
osdef.conf
configuration
options,
see
Appendix
B,
“Object
space
definition
configuration
file
reference,”
on
page
71.
Custom
shared
library
configuration
scenario
The
following
scenario
illustrates
the
use
of
the
configuration
options.
The
scenario
shows
three
Web
sites
using
CDAS.
The
first
site
uses
forms
as
the
login
method,
but
the
second
site
uses
certificates.
A
third
Web
site
uses
CDAS
for
single
signon,
but
uses
Tivoli
Access
Manager
for
basic
authentication.
Chapter
6.
Creating
a
Cross-domain
Authentication
Service
41
[Global]
...
cdas_loaded
=
yes
cdas_init_parameter
=
ldap
/etc/ldap.conf
cdas_init_parameter
=
cert
/etc/cert.conf
[Remote:
/ESproxy/reverse/newnovels.com]
domains
=
newnovels.com
login_method
=
forms
cdas_enabled
=
yes
cdas_auth_parameter
=
ldap
[Remote:
/ESproxy/reverse/newpoems.com]
domains
=
newpoems.com
login_method
=
certificate
cdas_enabled
=
yes
cdas_auth_parameter
=
cert
[Remote:
/ESproxy/reverse/newbooks.com]
domains
=
newbooks.com
login_method
=
basic
accept_sso
=
CDAS-MODULE
In
this
scenario,
xauthn_init
is
called
twice
with
the
argv[0]
=
ldap,
argv[1]
=
/etc/ldap.conf
initialization
options
on
the
first
call
and
the
argv[0]
=
cert,
argv[1]
=
/etc/cert/conf
initialization
options
on
the
second
call.
A
user
accessing
newnovels.com
is
authenticated
with
xauthn_extended_parameter
=
ldap,
but
a
user
accessing
newpoems.com
is
authenticated
with
xauthn_extended_parameter
=
cert.
The
CDAS
module
is
also
invoked
to
detect
pre-authenticated
users
accessing
newbooks.com.
The
CDAS
shared
library
can
simultaneously
support
multiple
user
repositories
and
perform
a
switch
based
on
the
xauthn_extended_parameter
value
it
receives.
Multiple
initializations
can
also
be
performed
based
on
the
argv[0]
option,
allowing
one
CDAS
shared
library
to
perform
the
functionality
that
would
otherwise
require
multiple
CDAS
libraries.
Configuring
the
demonstration
library
To
configure
the
CDAS
demonstration
library,
modify
the
configuration
options
in
the
osdef.conf
file.
For
example,
consider
the
options
shown
in
Figure
10.
Note:
For
the
demonstration
module,
basic_auth
and
cert
are
valid
values
for
cdas_auth_parameter.
In
this
example,
the
demonstration
module
is
configured
with
a
user
ID
and
password,
the
distinguished
name
of
the
corresponding
Tivoli
Access
Manager
user,
and
the
distinguished
name
of
a
certificate.
The
arguments
specified
by
the
cdas_init_parameter
are
passed
to
the
demonstration
module
when
the
xauthn_initialize
function
is
called.
The
following
values
are
passed
to
the
xauthn_initialize
routine:
[Global]
...
cdas_loaded=yes
cdas_init_parameter=demouser
userid
demopassword
password
democertdn
CertDN
validpddn
validpdDN
[Local]
cdas_enabled=yes
cdas_auth_parameter=basic_auth
Figure
10.
Example
of
configuration
options
in
osdef.conf
42
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
argc
=
8
argv[0]
=
demouser
argv[1]
=
userid
argv[2]
=
demopassword
argv[3]
=
password
argv[4]
=
democertdn
argv[5]
=
CertDN
argv[6]
=
validpddn
argv[7]
=
validpdDN
Authentication
is
performed
with
the
xauthn_authenticate
function
when
a
protected
resource
on
the
local
Web
server
is
accessed.
The
sample
module
checks
the
value
of
xauthn_extended_parameter
when
the
xauthn_authenticate
function
is
called.
If
basic_auth
is
passed
in,
the
user
ID
and
password
passed
in
are
checked
against
the
user
ID
and
password
that
were
passed
in
at
initialization
time.
If
cert
is
passed
in,
then
the
CertDN
passed
in
is
checked
against
the
CertDN
that
was
passed
in
at
initialization
time.
If
authentication
is
successful,
the
valid
Tivoli
Access
Manager
distinguished
name
is
returned
to
the
plug-in
for
authorization.
Loading
the
custom
shared
library
The
CDAS
shared
library
is
loaded
during
the
initialization
of
the
plug-in.
The
CDAS
library
file
can
be
found
at
one
of
the
following
locations:
v
For
UNIX
systems:
/opt/pdweb-lite/lib/libwslcdas.ext
where
ext
is
one
of
the
following:
–
For
AIX
systems:
a
–
For
Linux
systems:
so
–
For
Solaris
systems:
so
v
For
Windows
systems:
install_dir\bin\wslcdas.dll
If
you
want
the
plug-in
to
use
the
packaged
demonstration
CDAS
library,
do
one
of
the
following:
v
For
UNIX
systems,
replace
the
libwslcdas.ext
file
with
the
libcdasdemo.ext
file,
found
at
the
following
location:
/opt/pdweb-lite/samples/cdas_adk/example/libcdasdemo.ext
where
ext
is
one
of
the
following:
–
For
AIX
systems:
a
–
For
Linux
systems:
so
–
For
Solaris
systems:
so
v
For
Windows
systems,
replace
the
wslcdas.dll
file
with
the
cdasdemo.dll
file,
found
at
the
following
location:
install_dir\samples\cdas_adk\example\cdasdemo.dll
If
you
want
the
plug-in
to
use
a
custom
CDAS
shared
library,
do
one
of
the
following:
v
For
UNIX
systems,
replace
the
libwslcdas.ext
file
with
the
custom
CDAS
shared
library
file
where
ext
is
one
of
the
following:
–
For
AIX
systems:
a
–
For
Linux
systems:
so
Chapter
6.
Creating
a
Cross-domain
Authentication
Service
43
–
For
Solaris
systems:
so
v
For
Windows
systems,
replace
the
wslcdas.dll
file
with
the
custom
CDAS
shared
library
file.
Note:
If
a
problem
occurs
loading
your
custom
CDAS
shared
library,
you
can
revert
back
to
the
demonstration
CDAS
library.
CDAS
core
and
utility
functions
The
following
core
API
functions
must
be
implemented
in
your
custom
CDAS
shared
library:
v
xauthn_initialize
v
xauthn_shutdown
v
xauthn_authenticate
v
xauthn_change_password
The
CDAS
utility
library
is
located
in
the
one
of
the
following
directories:
v
For
UNIX
systems:
/opt/pdweb-lite/samples/cdas_adk/lib
v
For
Windows
systems:
install_dir\samples\cdas_adk\lib
The
static
library
file,
libpdxauthn.a
for
AIX,
Linux,
and
Solaris
or
pdxauthn.lib
for
Windows,
contains
the
utility
functions.
To
use
these
functions,
you
must
link
your
custom
shared
library
to
this
file.
The
following
utility
functions
facilitate
data
manipulation:
v
xnvlist_get
v
xattr_malloc
v
xattr_free
v
xattr_get
v
xattr_set
v
xattr_dup
The
xnvlist_get
function
retrieves
the
authentication
data
passed
in
from
the
plug-in.
The
remaining
utilities
allow
you
to
construct
extended
attributes
for
the
Tivoli
Access
Manager
identity.
For
more
information,
see
the
“CDAS
API
core
function
reference”
on
page
44.
For
more
information
about
utility
functions,
see
the
IBM
Tivoli
Access
Manager
WebSEAL
Developer’s
Reference.
CDAS
API
core
function
reference
This
section
lists
the
following
core
API
functions
used
to
implement
your
CDAS
shared
library:
v
xauthn_authenticate
v
xauthn_change_password
v
xauthn_initialize
v
xauthn_shutdown
44
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
xauthn_authenticate
Performs
the
CDAS
authentication.
xauthn_status_t
xauthn_authenticate(
xnvlist_t
*authnInfo,
xauthn_identity_t
*ident
);
Description
The
plug-in
calls
this
interface
to
perform
the
customer-specific
external
authentication.
Client
authentication
information
is
passed
by
the
plug-in
through
the
input
argument
authnInfo.
Refer
to
“User
authentication
data”
on
page
39
for
the
list
of
authentication
options
that
authnInfo
can
contain.
Based
on
the
authentication
information,
this
function
implements
the
specific
authentication
mechanism
and
stores
the
resulting
client
information
in
ident.
This
information
is
then
returned
to
the
plug-in.
It
is
important
to
note
that
the
client
identity
ident
can
contain
additional
user
information.
Options
Input
authnInfo
The
authnInfo
option
is
a
name/value
data
list
containing
client
authentication
information.
Input/Output
ident
The
ident
option
contains
the
authenticated
user
information.
Return
Codes
If
successful,
the
function
returns
XAUTHN_S_COMPLETE.
Possible
error
codes
can
be
found
in
the
pdxauthn.h
header
file.
Chapter
6.
Creating
a
Cross-domain
Authentication
Service
45
xauthn_change_password
Performs
the
CDAS
password
change.
xauthn_status_t
xauthn_change_password(
xnvlist_t
*authnInfo
);
Description
The
plug-in
calls
this
interface
to
implement
a
custom
password
change
mechanism.
This
interface
is
supported
only
for
the
user
name
and
password
authentication
mechanism.
Client
password
change
information
is
passed
by
the
plug-in
through
the
input
argument
authnInfo.
Refer
to
“User
authentication
data”
on
page
39
for
the
list
of
authentication
data
that
authnInfo
can
contain.
Options
Input
authnInfo
The
authnInfo
option
is
a
name/value
data
list
containing
client
authentication
information.
Return
Codes
If
successful,
the
function
returns
XAUTHN_S_COMPLETE.
XAUTHN_S_UNSUPPORTED_AUTHN_METHOD
is
returned
if
the
external
authentication
process
does
not
support
password
changes.
Possible
error
codes
can
be
found
in
the
pdxauthn.h
header
file.
46
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
xauthn_initialize
Initializes
the
CDAS
shared
library.
xauthn_status_t
xauthn_initialize(
int
argc,
const
char
**argv
);
Description
Use
this
function
to
initialize
an
authentication
shared
library.
The
input
options
argc
and
argv
are
built
from
options
specified
for
cdas_init_parameter
in
the
osdef.conf
configuration
file.
The
following
example
definition
illustrates
the
initialization
of
the
sample
CDAS
shared
library:
cdas_init_parameter
=
-dbms
sys.db
In
the
example,
xauthn_initialize
is
called
with
an
argc
value
of
2.
The
argv
array
contains
the
following
values:
argv[0]
=
“-dbms”
argv[1]
=
“sys.db”
Do
not
modify
input
options.
Options
Input
argc
The
number
of
arguments
contained
in
the
argv
array.
argv
The
string
arguments
passed
in
the
service
definition
for
this
service
instance.
Return
Codes
If
successful,
the
function
returns
XAUTHN_S_COMPLETE.
Possible
error
codes
can
be
found
in
the
pdxauthn.h
header
file.
Chapter
6.
Creating
a
Cross-domain
Authentication
Service
47
xauthn_shutdown
Shuts
down
the
CDAS
shared
library.
xauthn_status_t
xauthn_shutdown(
int
argc,
const
char
**argv
);
Description
During
normal
shutdown,
the
plug-in
calls
this
interface
to
perform
any
shut
down
processes
that
might
be
required
by
the
custom
environment.
The
input
options
argc
and
argv
are
built
from
the
options
specified
with
the
cdas_init_parameter
directive
in
the
osdef.conf
configuration
file.
The
following
example
illustrates
the
termination
of
the
sample
CDAS
shared
library:
cdas_init_parameter
=
-dbms
sys.db
In
the
example,
xauthn_shutdown
is
called
with
an
argc
value
of
2.
The
argv
array
contains
the
following
values:
argv[0]
=
“-dbms”
argv[1]
=
“sys.db”
Options
Input
argc
The
number
of
arguments
contained
in
the
argv
array.
argv
The
string
arguments
passed
in
the
service
definition
for
this
service
instance.
Return
Codes
If
successful,
the
function
returns
XAUTHN_S_COMPLETE.
Possible
error
codes
can
be
found
in
the
pdxauthn.h
header
file.
48
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Chapter
7.
Cross
domain
single
signon
solutions
When
Tivoli
Access
Manager
Plug-in
for
Edge
Server
is
implemented
as
a
proxy
server
to
provide
protection
to
a
secure
domain,
there
is
often
a
requirement
to
provide
solutions
for
single
signon
to
resources
across
unique
domains
and
servers.
This
chapter
discusses
two
cross-domain
single
signon
solutions.
Topic
Index:
v
“CDSSO
authentication”
v
“e-Community
single
signon”
on
page
55
CDSSO
authentication
Cross
domain
single
signon
(CDSSO)
provides
a
mechanism
for
transferring
user
credentials
between
Edge
Server
or
WebSEAL-protected
domains.
With
CDSSO
enabled,
a
Web
user
logs-in
once
and
can
then
access
resources
on
other
secure
domains
without
the
need
to
reauthenticate
each
time
a
resource
on
a
new
secure
domain
is
accessed.
The
CDSSO
authentication
mechanism
does
not
rely
on
a
Master
Authentication
Server
(see
“e-Community
single
signon”
on
page
55).
CDSSO
supports
the
goals
of
scalable
network
architecture
by
allowing
the
integration
of
multiple
secure
domains.
For
example,
a
large
corporate
extranet
can
be
set
up
with
two
or
more
unique
domains,
each
with
its
own
users
and
object
space.
CDSSO
allows
movement
of
users
between
the
domains
with
a
single
signon.
When
a
user
makes
a
request
to
a
resource
located
in
another
domain,
the
CDSSO
mechanism
transfers
an
encrypted
user
identity
token
from
the
first
domain
to
the
second
domain.
The
identity
information
in
this
token
indicates
to
the
receiving
domain
that
the
user
is
successfully
authenticated
in
the
first
domain.
The
identity
does
not
contain
password
information.
The
receiving
server
uses
this
token
to
build
credentials
in
its
own
cache
for
that
user.
The
user
is
not
forced
to
perform
an
additional
login.
Customizing
single
signon
authentication
Cross-domain
single
signon
solutions
employ
authentication
tokens
that
convey
an
encoded
version
of
the
user
identity
to
the
destination
server.
The
construction
of
these
tokens
by
the
initial
server
is
called
″token
creation″.
The
decoding
and
use
of
the
token
by
the
destination
server
is
called
″token
consumption″.
In
many
CDSSO
scenarios,
the
default
one-to-one
mapping
between
users
in
different
domains
might
not
suit
all
deployment
requirements.
The
Cross-domain
Mapping
FrameWork
(CDMF)
is
a
programming
interface
that
allows
you
to
build
a
custom
shared
library
that
can
handle
extended
user
attributes
and
provide
mapping
services
for
the
user
identity.
The
CDMF
programming
interface
allows
flexibility
in
customizing
the
mapping
of
user
identities
and
the
handling
of
user
attributes.
Complete
information
and
API
reference
material
for
CDMF
can
be
found
in
the
IBM
Tivoli
Access
Manager
WebSEAL
Developer’s
Reference.
©
Copyright
IBM
Corp.
2001,
2003
49
CDSSO
features
and
requirements
v
All
Edge
Servers
participating
in
CDSSO
must
have
machine
times
synchronized.
Authentication
between
servers
can
fail
when
machine
time
differences
are
too
great.
v
For
CDSSO
to
function
successfully,
each
participating
Edge
Server
must
reveal
its
fully
qualified
host
name
to
the
other
participating
servers
in
the
cross-domain
environment.
If
any
host
name
does
not
include
a
domain,
CDSSO
cannot
be
enabled
and
an
error
message
is
logged.
When
setting
up
a
CDSSO
environment,
ensure
that
the
machine-specific
networking
setup
for
each
participating
server
is
configured
to
identify
the
server
with
a
fully
qualified
host
name.
v
Because
some
plug-in
for
Edge
Server
configuration
requires
machine
host
names
to
be
described
as
fully
qualified
host
names,
you
must
ensure
that
your
system
and
network
can
resolve
machine
names
into
fully
qualified
host
names.
For
example,
using
fully
qualified
host
names
allows
for
many
host
names
(IP
addresses)
per
machine,
as
in
the
case
of
multiple
Edge
Server
instances.
Authentication
process
flow
for
CDSSO
with
CDMF
1.
Any
user
who
wants
to
participate
in
multiple
domains
must
have
a
valid
user
account
in
the
initial
domain
and
an
identity
that
can
be
mapped
into
a
valid
account
in
each
of
the
participating
remote
domains.
A
user
cannot
invoke
the
CDSSO
functionality
without
initially
authenticating
to
an
initial
secure
domain
(A)
that
contains
the
user’s
account.
2.
The
user
makes
a
request
to
access
a
resource
in
domain
B
using
a
custom
link
on
a
Web
page.
The
link
contains
a
special
CDSSO
management
page
expression:
/pkmscdsso?destination-URL
For
example:
http://market1.com/pkmscdsso?https://market2.com/resource.html
3.
The
request
is
first
processed
by
the
plug-in
for
Edge
Server
in
domain
A.
The
market1
server
builds
an
authentication
token
that
contains
the
user’s
credentials,
including
the
Tivoli
Access
Manager
identity
(short
name),
the
current
domain
(″market1″),
additional
user
information,
and
a
time
stamp.
This
process
is
performed
by
the
″token
create″
function
of
the
built-in
single
signon
authentication
mechanism
(library).
The
additional
user
information
(extended
attributes)
can
be
obtained
by
a
call
out
to
the
customized
CDMF
shared
library
(cdmf_get_usr_attributes).
This
library
has
the
ability
to
supply
user
attributes
that
can
be
used
by
domain
market2
during
the
user
mapping
process.
Triple-DES
encrypts
this
token
data
with
the
symmetric
key
generated
by
the
cdsso_key_gen
utility.
This
key
file
is
shared
and
stored
in
the
[Remote:
/ESproxy/reverse/domain-name]
stanza
of
the
osdef.conf
configuration
file
on
both
domain
market1
and
domain
market2
Edge
Server
plug-ins.
The
token
contains
a
configurable
time
stamp
(authtoken-lifetime)
that
defines
the
lifetime
of
the
token.
The
time
stamp,
when
properly
configured,
can
prevent
replay
attacks.
The
token
is
contained
in
a
redirected
request
to
the
destination
server,
using
the
URL
contained
in
the
pkmscdsso
link.
For
example:
http://market2.com/resource.html?PD-ID=encoded-authentication-token
4.
The
market1
server
redirects
the
request
containing
the
encrypted
token
back
to
the
browser
and
then
to
the
market2
server
(HTTP
redirection).
50
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
5.
The
market2
server
decodes
and
validates
the
token
as
coming
from
the
referring
domain.
This
process
is
performed
by
the
″token
consume″
function
of
the
built-in
single
signon
authentication
mechanism
(library).
6.
The
token
consume
functionality
can
further
call
out
to
a
customized
CDMF
library
which
performs
the
actual
user
mapping
(cdmf_map_usr).
The
CDMF
library
passes
the
user’s
identity,
and
any
extended
attribute
information,
back
to
the
token
consume
library.
The
token
consume
library
uses
this
information
to
build
a
credential.
7.
The
market2
authorization
service
permits
or
denies
access
to
protected
objects
based
on
the
user’s
credential
and
the
specific
ACL
permissions
associated
with
the
requested
objects.
Configuring
CDSSO
authentication
Enabling
and
disabling
CDSSO
authentication
For
CDSSO,
the
cross
domain
single
signon
module
must
be
loaded
and
initialized.
To
configure
this,
assign
the
value
yes
to
the
cdsso_loaded
parameter
which
is
a
global
parameter
in
the
osdef.conf
configuration
file.
[Global]
cdsso_loaded
=
yes
The
default
value
of
the
cdsso_loaded
parameter
is
no.
To
enable
CDSSO
authentication,
assign
the
value
yes
to
the
cdsso_enabled
parameter
in
the
osdef.conf
configuration
file.
[Global]
cdsso_enabled
=
yes
cdsso_loaded
=
yes
The
cdsso_enabled
parameter
is
not
necessarily
a
global
parameter
as
it
can
be
used
to
enable
and
disable
CDSSO
authentication
for
specific
domains
using
the
[Remote:
....]
stanza.
For
example:
[Global]
...
cdsso_loaded
=
yes
...
[Remote:
/ESproxy/reverse/market1.com]
...
cdsso_enabled
=
yes
[Remote:
/ESproxy/reverse/market2.com]
...
cdsso_enabled
=
no
Creating
the
CDSSO
HTML
link
The
HTML
link
(located
on
the
original
server)
that
connects
the
user
to
a
resource
on
the
destination
server
must
use
a
special
CDSSO
expression
that
directs
the
request
to
a
CDSSO
management
page.
This
special
expression
is
defined
using
the
global
parameter,
cdsso_link_url.
The
default
value
is
pkmscdsso.
Usage:
/pkmscdsso?destination-URL
For
example:
http://edgeserverA/pkmscdsso?https://edgeserverB/resource.html
Chapter
7.
Cross
domain
single
signon
solutions
51
Configuring
the
token
label
name
The
authentication
information
used
for
a
single
signon
transaction
is
placed
in
the
redirected
request
as
an
encrypted
token
query
string
argument
to
the
request.
This
token
string
requires
a
name,
or
label,
to
identify
it.
The
label
name
uniquely
identifies
the
request
to
the
receiving
Edge
Server
plug-in
as
a
single
signon
request
to
be
handled
by
the
CDSSO
token
consume
mechanism
(library).
You
must
configure
this
token
label
on
all
Edge
Server
plug-ins
participating
in
the
single
signon
functionality.
To
configure
the
token
label,
use
the
global
parameter,
cdsso-link-argument,
of
the
osdef.conf
configuration
file.
For
example
(default):
cdsso-link-argument
=
PD-ID
The
token
create
library
creates
and
encodes
an
authentication
token
(containing
the
user’s
identity
information)
and
includes
this
token
in
a
redirected
request
to
the
resource
using
the
destination
URL
information
from
the
CDSSO
link.
For
example:
http://edgeserverB/resource.html?PD-ID=encoded-authentication-token
Encrypting
the
authentication
token
data
The
authentication
data
placed
in
the
token
is
encrypted
using
a
key
generated
by
the
cdsso_key_gen
utility.
You
must
″synchronize″
this
key
by
sharing
the
key
file
with
each
participating
Edge
Server
plug-in
in
each
participating
domain.
Each
participating
Edge
Server
plug-in
in
each
domain
needs
to
use
the
same
key.
The
generated
key
is
a
triple
DES
192
bit
key.
You
cannot
specify
a
life
span
time
on
this
key.
Note:
The
distribution
of
key
files
is
not
a
part
of
the
Tivoli
Access
Manager
CDSSO
process.
The
cdsso_key_gen
utility
requires
that
you
specify
the
location
(absolute
pathname)
of
the
key
file
when
you
run
the
utility.
You
must
also
use
a
full
path
name
to
run
this
utility:
Linux:
#
install_path/bin/cdsso_key_gen
keyfile-location
Other
platforms:
For
platforms
other
than
Linux
the
cdsso_key_gen
utility
can
be
accessed
from
the
Tivoli
Access
Manager
runtime
Environment.
Enter
this
key
file
location
in
the
[Remote:
/ESproxy/reverse/domain-nam,e]
stanza
of
the
osdef.conf
configuration
file
of
the
participating
Edge
Server
plug-in
in
each
domain.
The
format
must
include
the
full
location
of
the
key
and
the
external
domain
the
key
relates
to:
[Remote:
/ESproxy/reverse/domain-name]
cdsso_keyfile
=
path-name-where-key-is-stored
external-domain-name
Configuration
example
for
domain
market1.com:
[Remote:
/ESproxy/reverse/market1.com]
cdsso_keyfile
=
/opt/pdweb-lite/etc/market12.key
market2.com
This
setting
specifies
the
key
market12.key
is
used
to
encrypt
a
token
destined
for
the
market2.com
domain.
52
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Configuration
example
for
domain
market2.com:
[Remote:
/ESproxy/reverse/market2.com]
cdsso_keyfile
=
/opt/pdweb-lite/etc/market12.key
market1.com
This
setting
specifies
the
key
market12.key
is
used
to
encrypt
a
token
destined
for
the
market1.com
domain.
In
the
above
example,
the
market12.key
file
is
generated
in
one
domain
(market1.com,
for
example)
and
manually
(and
securely)
copied
to
the
other
domain
(market2.com,
for
example).
CDSSO
group
specific
configuration
The
name
of
the
CDSSO
group
is
specified
using
the
cdsso-group
parameter
located
in
the
[Remote:
/ESproxy/reverse/domain]
stanza.
This
parameter
must
be
specified
on
all
machines
participating
within
the
CDSSO
group.
If
unspecified,
CDSSO
remains
disabled
for
this
server.
The
name
given
to
the
CDSSO
group
is
used
to
specify
another
configuration
stanza,
[CDSSOGROUP:
CDSSO_group_name]
within
which
CDSSO
group
specific
configuration
is
specified.
For
example:
Market1
Domain
[Remote:
/ESproxy/reverse/market1]
...
cdsso_group
=
market_cdsso
....
[CDSSOGROUP:
market_cdsso]
...
Specifying
CDSSO
group
names
in
this
way
permits
involvement
of
a
Edge
Server
plug-in
enhanced
server
in
more
than
one
CDSSO
group.
Configuring
the
token
time
stamp:
The
token
contains
a
configurable
time
stamp
that
defines
the
lifetime
of
the
identity
token.
After
the
time
stamp
has
expired,
the
token
is
considered
invalid
and
is
not
used.
The
time
stamp
is
used
to
help
prevent
replay
attacks
by
setting
a
value
short
enough
to
prevent
the
token
from
being
stolen
and
replayed
within
its
lifetime.
The
token_lifetime
parameter,
located
in
the
[CDSSOGROUP:
cdsso-group-name]
configuration
stanza,
sets
the
token
lifetime
value.
The
value
is
expressed
in
minutes.
The
default
value
is
30:
[CDSSOGROUP:
cdsso-group-name]
token-lifetime
=
30
You
must
take
into
account
any
clock
skew
among
the
participating
domains.
Configuring
the
SSO
type
and
token
security:
Two
other
parameters
require
configuration
within
the
[CDSSOGROUP:
cdsso-group-name]
stanza:
type
and
token_security.
The
type
parameter
indicates
cross
domain
single
signon
configuration
type.
For
cross
domain
single
signon
the
value
for
this
parameter
will
be
CDSSO.
The
token_security
parameter
indicates
the
level
of
security
used
to
encrypt
the
authentication
token.
Valid
options
for
this
parameter
are
either,
privacy
or
privacy_integrity.
The
default
value
is
privacy.
Specifying
the
value
privacy
ensures
Chapter
7.
Cross
domain
single
signon
solutions
53
token
information
is
encrypted
to
ensure
privacy.
Specifying
the
value
privacy_integrity
ensures
token
information
is
encrypted
and
signed
to
ensure
privacy
and
integrity.
Protecting
the
authentication
token
While
the
authentication
token
does
not
contain
authentication
information
(such
as
user
name
and
password),
it
does
contain
a
user
identity
that
is
trusted
within
the
receiving
domain.
The
token
itself
must
therefore
be
protected
against
theft
and
replay.
The
token
is
protected
against
theft
off
the
wire
through
the
use
of
SSL
to
secure
communications
between
the
Edge
Server
plug-ins
and
the
users.
The
token
could
conceivably
be
stolen
from
the
user’s
browser
history.
The
time
stamp
on
the
token
should
be
short
enough
to
make
it
unlikely
that
the
token
could
be
stolen
and
replayed
during
the
lifetime
of
the
token.
However,
a
token
that
has
expired
with
respect
to
its
time
stamp
is
still
vulnerable
to
cryptographic
attacks.
If
the
key
used
to
encrypt
the
token
is
discovered
or
otherwise
compromised,
malicious
users
could
build
their
own
tokens.
These
tokens
could
then
be
inserted
into
a
″pseudo-CDSSO
flow″.
They
would
be
indistinguishable
from
real
authentication
tokens
to
the
Edge
Server
plug-ins
participating
in
the
CDSSO
domain.
For
this
reason,
the
keys
used
to
protect
the
tokens
must
also
be
carefully
managed
and
changed
on
a
regular
basis.
An
example
CDSSO
configuration
---------
All
domains
---------
[Global]
cdsso_loaded
=
yes
cdsso_enabled
=
yes
#
CDSSO
configuration
cdsso_link_url
=
/pkmscdsso
cdsso_link_argument
=
PD-ID
#
ECSSO
configuration
cdsso_ecom_vouch_url
=
/pkmsvouchfor
cdsso_ecom_vouch_argument
=
PD-VF
---------
market1.com
---------
[Remote:
/ESproxy/reverse/market1.com]
domains
=
market1.com
login_method
=
basic
route
=
http://backend1.com
cdsso_group
=
market_cdsso
cdsso_keyfile
=
/opt/pdweb-lite/etc/market12.key
market2.com
cdsso_keyfile
=
/opt/pdweb-lite/etc/market13.key
market3.com
[CDSSOGROUP:
market_cdsso]
type
=
CDSSO
token_security
=
privacy
token_lifetime
=
30
---------
market2.com
---------
[Remote:
/ESproxy/reverse/market2.com]
domains
=
market2.com
login_method
=
forms
route
=
http://backend2.com
cdsso_group
=
market_cdsso
cdsso_keyfile
=
/opt/pdweb-lite/etc/market12.key
market1.com
cdsso_keyfile
=
/opt/pdweb-lite/etc/market23.key
market3.com
54
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
[CDSSOGROUP:
market_cdsso]
type
=
CDSSO
token_security
=
privacy
token_lifetime
=
30
---------
market3.com
---------
[Remote:
/ESproxy/reverse/market3.com]
domains
=
market3.com
login_method
=
certificate
route
=
http://backend3.com
cdsso_group
=
market_cdsso
cdsso_keyfile
=
/opt/pdweb-lite/etc/market13.key
market1.com
cdsso_keyfile
=
/opt/pdweb-lite/etc/market23.key
market2.com
[CDSSOGROUP:
market_cdsso]
type
=
CDSSO
token_security
=
privacy
token_lifetime
=
30
Note:
Configuration
of
the
plug-in
for
cross
domain
single
sign-on
is
simple
because
the
configuration
files
can
be
easily
distributed
to
other
machines
without
modification.
In
a
virtual
hosting
environment,
a
single
configuration
file
may
be
used
on
the
machine
that
hosts
the
domains.
Alternatively,
the
configuration
files
may
be
distributed
to
multiple
machines,
if
the
domains
are
distributed
across
multiple
physical
machines.
However,
CDSSO
does
require
the
web
administrator
to
modify
the
URLs
that
link
between
the
two
web
sites,
by
adding
/pkmscdsso?
In
front
of
the
link.
e-Community
single
signon
Tivoli
Access
Manager
Plug-in
for
Edge
Server’s
e-community
single
signon
functionality
allows
users
to
access
resources
across
multiple
servers
in
multiple
domains
without
requiring
re-authentication.
An
″e-community″
is
a
group
of
distinct
domains
(Tivoli
Access
Manager
or
DNS)
that
participate
in
a
business
relationship.
These
participating
domains
can
be
configured
as
part
of
one
business
(and
perhaps
using
different
DNS
names
for
geographic
reasons)
or
as
different
businesses
with
a
shared
relationship.
In
either
scenario,
there
is
always
one
domain
that
is
designated
the
″home″
or
″owner″
domain.
In
the
case
of
participating
businesses,
the
home
domain
owns
the
business
agreements
that
govern
the
e-community.
In
both
scenarios,
authentication
information
about
the
users
who
participate
in
the
e-community
(including
the
user
names
and
passwords
used
for
authentication)
is
maintained
in
the
home
domain.
This
arrangement
allows
a
single
point
of
reference
for
administration
issues,
such
as
help
desk
calls
within
the
e-community
that
all
refer
to
the
home
domain.
Alternatively,
you
can
use
the
Tivoli
Access
Manager
Web
Portal
Manager
to
delegate
the
management
of
this
information
such
that
participating
domains
have
responsibility
for
the
administration
of
their
own
users.
The
home
domain
″owns″
the
users
–
that
is,
it
controls
the
user’s
authentication
information.
Regardless
of
where
a
user
makes
a
request
for
resources,
the
home
domain
is
always
where
the
user
must
be
authenticated.
Chapter
7.
Cross
domain
single
signon
solutions
55
Authentication
occurs
against
a
master
authentication
server
(MAS)
–
a
server
(or
set
of
replica
servers)
that
is
located
in
the
home
domain
and
configured
to
authenticate
all
users.
The
duty
of
the
MAS
should
be
restricted
to
providing
authentication
services.
The
MAS
should
not
contain
resources
that
are
available
to
users.
After
a
user
has
successfully
authenticated
to
the
MAS,
the
MAS
generates
a
vouch-for
token.
This
token
is
passed
back
to
the
server
where
the
user
is
making
the
request.
The
server
treats
this
vouch-for
token
as
proof
that
the
user
has
successfully
authenticated
to
the
MAS
and
can
participate
in
the
e-community.
The
transfer
of
information
between
e-community
domains
is
described
in
detail
in
the
section
“e-Community
single
signon
process
flow.”
e-Community
single
signon
features
and
requirements
v
e-Community
functionality
supports
access
using
direct
URLs
(bookmarks)
to
resources.
v
e-Community
implementation
requires
a
consistent
configuration
across
all
plug-ins
in
all
domains
participating
in
the
e-community.
v
All
users
who
are
participating
in
the
e-community
authenticate
against
a
single
master
authentication
server
(MAS)
located
in
the
home
domain.
v
The
e-community
implementation
allows
for
″local″
authentication
in
remote
domains
if
the
user
does
not
have
a
valid
account
with
the
MAS.
A
user
who
fails
authentication
with
the
MAS
when
requesting
a
resource
in
a
non-MAS
(but
participating)
domain
is
given
the
option
to
authenticate
to
the
local
server
where
the
request
is
being
made.
v
The
MAS
(and
eventually
other
selected
servers
in
the
remote
domains)
vouch-for
the
user’s
authenticated
identity.
v
Domain-specific
cookies
are
used
to
identify
the
server
that
can
provide
vouch-for
services.
This
allows
servers
in
a
remote
domain
to
request
vouch-for
information
locally.
The
encrypted
contents
of
e-community
cookies
do
not
contain
user
identity
or
security
information.
v
Special
tokens
are
used
to
pass
encrypted
″vouched
for″
user
identities.
The
vouch-for
token
does
not
contain
actual
user
authentication
information.
Integrity
is
provided
by
shared
secret
key
(triple-DES).
The
token
contains
a
time-out
(lifetime)
value
to
limit
the
duration
of
the
token
validity.
v
The
e-community
implementation
is
supported
on
both
HTTP
and
HTTPS.
v
Configuration
for
e-community
is
set
in
the
osdef.conf
file
of
each
participating
plug-in.
e-Community
single
signon
process
flow
An
e-community
consists
of
a
plug-in-enhanced
master
authentication
server
(MAS)
and
additional
plug-in-enhanced
servers
acting
as
an
e-community.
The
e-community
single
signon
solution
can
also
interoperate
with
WebSEAL
protected
resources.
The
e-community
implementation
is
based
on
a
vouch-for
system.
Normally,
when
unauthenticated
users
request
a
resource
through
the
plug-in
they
are
prompted
for
authentication
information.
In
an
e-community
configuration,
the
plug-in
server
identifies
a
vouch-for
server
and
requests
verification
from
this
vouch-for
server
that
the
user
has
authenticated.
The
vouch-for
server
stores
valid
credential
information
for
the
user.
56
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
For
the
user’s
first
request,
the
vouch-for
server
is
always
the
MAS.
The
MAS
continues
to
serve
as
the
vouch-for
server
for
resources
located
in
the
home
domain.
As
the
user
continues
with
resource
requests
across
the
e-community,
an
individual
server
in
each
remote
domain
can
build
its
own
credential
for
the
user
(based
on
user
identity
information
from
the
MAS)
and
assume
the
role
of
vouch-for
server
for
resources
in
its
domain.
1
plug-in
BookClube-community
plu
g-in
ww1.newbooks.com
plu
g-in
ww2.newbooks.com
newbooks.comDomain
plu
g-in
plu
g-in
MAS
ww1.newnovels.com
ww2.newnovels.com
newnovels.comDomain
2 3
mas.newbooks.com
SD
Client Browser
The
example
above
shows
two
domains,
IBM
domain
and
Lotus
domain,
that
exist
within
an
e-community.
The
following
processes
take
place
the
first
time
a
user
logs
on
to
a
secure
Web
site
within
the
e-community:
1.
The
user
requests
access
to
a
resource
on
the
Web
server
newbooks.com.
The
plug-in
intercepts
the
request
and
confirms
that
newbooks.com
is
configured
as
part
of
the
book_community
e-community.
The
MAS
server
in
the
e-community
is
identified
from
the
newbooks.com
configuration.
2.
The
request
is
passed
to
the
MAS
-
mas.newbooks.com.
The
MAS
authenticates
the
request
on
behalf
of
newbooks.com
and
issues
a
vouch-for
token
that
becomes
the
user’s
e-community
identity.
The
user
identity
information
in
the
token
is
encrypted.
3.
The
MAS
sends
the
vouch-for
token
to
newbooks.com.
newbooks.com
treats
this
vouch-for
token
as
proof
that
the
user
has
successfully
authenticated
to
the
MAS
and
can
now
access
the
requested
resource
based
on
normal
authorization
controls.
Figure
11.
Logging
into
an
e-community.
Chapter
7.
Cross
domain
single
signon
solutions
57
The
e-community
cookie
v
The
e-community
cookie
is
a
domain-specific
cookie
set
by
one
plug-in,
stored
in
the
memory
of
the
user’s
browser,
and
transmitted
to
other
plug-in
instances
(in
the
same
domain)
in
subsequent
requests.
v
The
domain-specific
cookie
contains
the
name
of
the
vouch-for
server,
the
e-community
identity,
a
location
(URL)
of
the
vouch-for
server
and
functionality,
and
a
lifetime
value.
The
cookie
contains
no
user
information.
v
The
e-community
cookie
allows
servers
in
participating
domains
to
request
vouch-for
information
locally.
The
e-community
cookie
for
the
domain
where
the
MAS
is
located
plays
a
less
significant
role.
v
The
cookie
has
a
lifetime
(timeout)
value
that
is
set
in
the
osdef.conf
configuration
file.
This
lifetime
value
specifies
how
long
a
remote
server
is
able
to
provide
vouch-for
information
for
the
user.
When
the
cookie
lifetime
has
expired,
the
user
must
be
redirected
to
the
MAS
for
authentication.
v
The
cookie
is
cleared
from
memory
when
the
browser
is
closed.
If
the
user
logs
out
of
a
specific
domain,
the
e-community
cookie
is
overwritten
as
empty.
This
action
effectively
removes
it
from
the
browser.
The
vouch-for
request
and
reply
The
e-community
vouch-for
operation
requires
dedicated
functionality
accessed
through
two
specially
constructed
URLs:
the
vouch-for
request
and
the
vouch-for
reply.
These
URLs
are
constructed
during
the
e-community
vouch-for
HTTP
re-directs
based
on
the
configuration
information
in
osdef.conf.
The
vouch-for
request
The
vouch-for
request
is
triggered
when
a
user
requests
a
resource
from
a
target
server
(configured
for
e-community)
that
contains
no
credential
information
for
that
user.
The
server
sends
an
HTTP
re-direct
to
the
vouch-for
server
(either
the
MAS
or
a
server
identified
in
an
e-community
cookie).
The
vouch-for
request
contains
the
following
information:
https://vouch_for_server/pkmsvouchfor?ecommunity_name&target_url
The
receiving
server
checks
the
ecommunity_name
to
validate
the
e-community
identity.
The
receiving
server
uses
the
target_url
in
the
vouch-for
reply
to
re-direct
the
browser
back
to
the
originally
requested
page.
The
vouch-for
URL
is
configured
using
the
cdsso_ecom_vouch_url
parameter.
The
default
value
is
/pkmsvouchfor.
For
example:
https://mas.newbooks.com/pkmsvouchfor?book_community&https://newbooks.com/index.html
The
vouch-for
reply
The
vouch-for
reply
is
the
response
from
the
vouch-for
server
to
the
target
server.
The
vouch-for
reply
contains
the
following
information:
https://target_url?PD-VF=vouch_for_server&PD-VF=encrypted_token
The
name
of
the
argument
in
the
URL
that
contains
the
encrypted
token
is
specified
using
the
cdsso_ecom_vouch_argument
parameter.
The
default
value
is
PD-VF.
For
example:
58
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
https://ww1.newbooks.com/index.html?PD-VFHOST=www.newbooks.com&PD-VF=3qhe...ge56wgb
The
vouch-for
token
In
order
to
achieve
cross-domain
single
signon,
some
user
identity
information
must
be
transmitted
between
servers.
This
sensitive
information
is
handled
using
a
re-direct
that
includes
the
identity
information
encrypted
as
part
of
the
URL.
This
encrypted
data
is
called
a
vouch-for
token.
v
The
token
contains
the
vouch-for
success
or
failure
status,
the
user’s
identity
(if
successful),
the
fully
qualified
name
of
the
server
that
created
the
token,
the
e-community
identity,
and
a
creation
time
value.
v
The
holder
of
a
valid
vouch-for
token
can
use
this
token
to
establish
a
session
(and
set
of
credentials)
at
a
server
without
explicitly
authenticating
to
that
server.
v
The
token
is
encrypted
using
a
shared
triple-DES
secret
key
so
that
its
authenticity
can
be
verified.
v
Encrypted
token
information
is
not
stored
on
the
browser.
v
The
token
is
passed
only
once.
The
receiving
server
uses
this
information
to
build
user
credentials
in
its
own
cache.
The
server
uses
these
credentials
for
future
requests
by
that
user
during
the
same
session.
v
The
token
has
a
lifetime
(timeout)
value
that
is
set
in
the
osdef.conf
configuration
file.
This
value
can
be
very
short
(seconds)
to
reduce
the
risk
of
a
re-play
attack.
Encrypting
the
authentication
token
data
The
authentication
data
placed
in
the
token
is
encrypted
using
a
key
generated
by
the
cdsso_key_gen
utility.
Within
the
MAS
server
configuration
you
must
specify
the
keys
used
to
encrypt
the
tokens
for
each
participating
domain.
Each
participating
Edge
Server
plug-in
in
each
domain
needs
to
use
the
same
key.
The
generated
key
is
a
triple
DES
192
bit
key.
You
cannot
specify
a
lifetime
on
this
key.
Note:
The
distribution
of
key
files
is
not
a
part
of
the
Tivoli
Access
Manager
CDSSO
process.
The
cdsso_key_gen
utility
requires
that
you
specify
the
location
(absolute
pathname)
of
the
key
file
when
you
run
the
utility.
You
must
also
use
a
full
path
name
to
run
this
utility:
Linux:
#
install_path/bin/cdsso_key_gen
keyfile-location
Other
platforms:
For
platforms
other
than
Linux
the
cdsso_key_gen
utility
can
be
accessed
from
the
Tivoli
Access
Manager
runtime
Environment.
On
the
MAS
server
configure
each
key
file
location
in
the
[Remote:
/ESproxy/reverse/domain-name]
stanza
of
the
osdef.conf
configuration
file,
in
the
format:
[Remote:
/ESproxy/reverse/domain-name]
cdsso_keyfile
=
path-name-where-key-is-stored
external-domain-name
Chapter
7.
Cross
domain
single
signon
solutions
59
Configuration
example
for
the
MAS
domain
mas.newbooks.com:
[Remote:
/ESproxy/reverse/newbooks.com]
cdsso_keyfile
=
/opt/pdweb-lite/etc/newbooks.key
*.newbooks.com
cdsso_keyfile
=
/opt/pdweb-lite/etc/newnovels.key
*.newnovels.com
The
above
configuration
for
the
MAS
specifies
the
key
newbooks.key
used
to
encrypt
the
token
destined
for
all
servers
with
the
newbooks.com
domain
and
the
key
newnovels.key
used
to
encrypt
the
token
destined
for
all
servers
in
the
newnovels.com
domain.
On
each
participating
server
in
the
e-community
you
need
to
configure
the
path
to
the
key
used
to
encrypt
the
token.
As
an
example,
encryption
key
configuration
for
server
ww1.newbooks.com
in
domain
newbooks.com
would
look
like:
[Remote:
/ESproxy/reverse/newbooks.com]
...
cdsso_keyfile
=
/opt/pdweb-lite/etc/newbooks.key
This
setting
specifies
the
key
newbooks.key
is
used
to
encrypt
the
token
sent
between
the
MAS,
mas.newbooks.com
and
the
server
ww1.newbooks.com.
The
newbooks.key
file
is
generated
in
one
domain
(mas.newbooks.com,
for
example)
and
manually
(and
securely)
copied
to
the
other
server
(ww1.newbooks.com,
for
example).
Enabling
and
disabling
e-community
single
signon
For
e-community
single
signon,
the
cross
domain
single
signon
module
must
be
loaded
and
initialized.
To
configure
this,
assign
the
value
yes
to
the
cdsso_loaded
parameter
which
is
a
global
parameter
in
the
osdef.conf
configuration
file.
[Global]
cdsso_loaded
=
yes
The
default
value
of
the
cdsso_loaded
parameter
is
no.
To
enable
CDSSO
authentication,
assign
the
value
yes
to
the
cdsso_enabled
parameter
in
the
osdef.conf
configuration
file.
[Global]
cdsso_enabled
=
yes
cdsso_loaded
=
yes
The
cdsso_enabled
parameter
is
not
necessarily
a
global
parameter
as
it
can
be
used
to
enable
and
disable
CDSSO
authentication
for
specific
domains
using
the
[Remote:
....]
stanza.
For
example:
[Global]
...
cdsso_loaded
=
yes
...
[Remote:
/ESproxy/reverse/newbooks.com]
...
cdsso_enabled
=
yes
...
[Remote:
/ESproxy/reverse/newbooksold.com]
...
cdsso_enabled
=
no
...
60
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Configuring
an
e-community
This
section
reviews
the
configuration
parameters
required
for
an
e-community
implementation.
These
parameters
are
located
in
the
osdef.conf
file.
You
must
carefully
configure
this
file
for
each
participating
Edge
Server
plug-in
in
the
e-community.
Configuring
the
CDSSO
typeThe
type
parameter
indicates
cross
domain
single
signon
configuration
type.
For
e-community
cross
domain
single
signon
the
value
for
this
parameter
will
be
ECSSO.
Configuring
the
CDSSO
group
nameThe
name
of
the
CDSSO
group
is
specified
using
the
cdsso-group
parameter
located
in
the
[Remote:
/ESproxy/reverse/domain-name]
stanza.
This
parameter
must
be
specified
on
all
machines
participating
within
the
CDSSO
e-community.
If
unspecified,
e-community
single
signon
remains
disabled
for
this
server.
The
name
given
to
the
CDSSO
group
is
used
to
specify
another
configuration
stanza,
[CDSSOGROUP:
CDSSO_group_name]
within
which
CDSSO
group
specific
configuration
is
specified.
For
example:
newbooks.com
[Remote:
/ESproxy/reverse/newbooks.com]
...
cdsso_group
=
book_community
...
[CDSSOGROUP:
book_community]
...
Specifying
CDSSO
group
names
in
this
way
permits
involvement
of
a
Edge
Server
plug-in
enhanced
server
in
more
than
one
CDSSO
group.
Configuring
the
e-community
nameThe
ecom_community
parameter
identifies
the
name
of
the
e-community
the
server
belongs
to.
For
example:
[CDSSOGROUP:
book_community]
ecom_community
=
BookClub
The
ecom_community
value
must
be
the
same
for
all
members
of
an
e-community.
Identifying
the
Master
Authentication
Server
(MAS)The
ecom_master_server
parameter
identifies
the
MAS
within
the
e-community.
This
value
must
be
specified
in
all
osdef.conf
configuration
files
on
all
participating
Edge
Server
plug-in
instances.
[CDSSOGROUP:
book_community]
...
ecom_master_server
=
mas.newbooks.com
...
Configuring
the
token
lifetimeThe
ecom_vouch_lifetime
parameter
sets
the
lifetime
of
the
e-community
domain
cookie
created
by
the
server
that
will
vouch
for
other
servers
within
the
domain.
The
default
value
is
300
minutes.
[CDSSOGROUP:
book_community]
...
ecom_vouch_lifetime
=
300
...
Chapter
7.
Cross
domain
single
signon
solutions
61
Configuring
e-community
single
signon
-
an
example
configuration
---------
All
domains
---------
[Global]
cdsso_loaded
=
yes
cdsso_enabled
=
yes
#
CDSSO
configuration
cdsso_link_url
=
/pkmscdsso
cdsso_link_argument
=
PD-ID
#
ECSSO
configuration
cdsso_ecom_vouch_url
=
/pkmsvouchfor
cdsso_ecom_vouch_argument
=
PD-VF
---------
mas.newbooks.com
---------
[Remote:
/ESproxy/reverse/mas.newbooks.com]
domains
=
mas.newbooks.com
#
Only
cdsso
config
options
are
valid
when
#
acting
as
a
master
authentication
server
cdsso_group
=
book_community
#
Intra-domain
cookie
key
file
cdsso_keyfile
=
/opt/pdweb-lite/etc/newbooks.key
*.newbooks.com
cdsso_keyfile
=
/opt/pdweb-lite/etc/newnovels.key
*.newnovels.com
[Remote:
/ESproxy/reverse/newbooks.com]
domains
=
newbooks.com
login_method
=
basic
route
=
http://backend1.com
cdsso_group
=
book_community
cdsso_keyfile
=
/opt/pdweb-lite/etc/newbooks.key
[Remote:
/ESproxy/reverse/newnovels.com]
domains
=
newnovels.com
login_method
=
forms
route
=
http://backend2.com
cdsso_group
=
book_community
cdsso_keyfile
=
/opt/pdweb-lite/etc/newnovels.key
[CDSSOGROUP:
book_community]
type
=
ECSSO
ecom_community
=
BookClub
ecom_master_server
=
mas.newbooks.com
---------
newbooks.com
---------
[Remote:
/ESproxy/reverse/newbooks.com]
domains
=
newbooks.com
login_method
=
basic
route
=
http://backend1.com
cdsso_group
=
book_community
cdsso_keyfile
=
/opt/pdweb-lite/etc/newbooks.key
[CDSSOGROUP:
book_community]
type
=
ECSSO
ecom_community
=
BookClub
62
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
ecom_master_server
=
mas.newbooks.com
---------
newnovels.com
---------
[Remote:
/ESproxy/reverse/newnovels.com]
domains
=
newnovels.com
login_method
=
forms
route
=
http://backend2.com
cdsso_group
=
book_community
cdsso_keyfile
=
/opt/pdweb-lite/etc/newnovels.key
[CDSSOGROUP:
book_community]
type
=
ECSSO
ecom_community
=
BookClub
ecom_master_server
=
mas.newbooks.com
Chapter
7.
Cross
domain
single
signon
solutions
63
64
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Chapter
8.
Removing
the
plug-in
for
Edge
Server
This
chapter
describes
how
to
unconfigure
and
remove
the
plug-in
for
Edge
Server.
To
unconfigure
and
remove
the
plug-in,
complete
the
instructions
in
one
of
the
following
sections:
v
“Removing
the
plug-in
for
Edge
Server
on
AIX”
on
page
65
v
“Removing
the
plug-in
for
Edge
Server
on
Linux”
on
page
66
v
“Removing
the
plug-in
for
Edge
Server
on
Solaris”
on
page
66
v
“Removing
the
plug-in
for
Edge
Server
on
Windows”
on
page
67
Removing
the
plug-in
for
Edge
Server
on
AIX
Removal
of
the
plug-in
for
Edge
Server
on
AIX
is
a
two-part
process.
You
must
first
unconfigure
the
plug-in
package
and
then
remove
it.
To
unconfigure
the
plug-in
package
on
AIX,
do
the
following:
1.
Log
in
as
root.
2.
Enter
the
following
command:
wslconfig.sh
-u
3.
Enter
the
user
ID
for
the
IBM
Tivoli
Access
Manager
administrative
user.
You
can
press
Enter
to
accept
the
default
user
of
sec_master.
A
prompt
appears
requesting
the
password
for
the
Tivoli
Access
Manager
administrator.
4.
Enter
the
password
for
sec_master.
A
series
of
status
messages
appear.
The
plug-in
for
Edge
Server
logs
in
to
the
Tivoli
Access
Manager
policy
server
and
unconfigures
itself.
The
unconfiguration
completes
and
the
wslconfig
utility
exits.
To
remove
the
plug-in
package
and
any
dependent
software
on
AIX,
enter
the
following:
installp
-u
-g
PDPlgES
Note:
Use
the
–g
option
only
if
you
want
dependent
software
for
the
specified
package
removed.
The
plug-in
for
Edge
Server
files
are
removed.
The
installp
utility
exits.
Removal
of
the
plug-in
for
Edge
Server
on
AIX
is
complete.
Note:
You
may
find
that
the
unconfiguration
and
uninstallation
processes
do
not
fully
clean-up
the
plug-in
installation
directory.
To
completely
remove
the
product
run
the
command,
rm
-rf
/opt/pdweb-lite.
If
you
want
to
remove
prerequisite
Tivoli
Access
Manager
components,
follow
the
removal
instructions
in
the
IBM
Tivoli
Access
Manager
Base
Installation
Guide.
©
Copyright
IBM
Corp.
2001,
2003
65
Removing
the
plug-in
for
Edge
Server
on
Linux
Removal
of
the
plug-in
for
Edge
Server
on
Linux
is
a
two-part
process.
You
must
first
unconfigure
the
plug-in
package
and
then
remove
it.
To
unconfigure
the
plug-in
on
Linux,
do
the
following:
1.
Log
in
as
root.
2.
Enter
the
following
command:
wslconfig.sh
-u
3.
Enter
the
user
ID
for
the
Tivoli
Access
Manager
administrative
user.
You
can
press
Enter
to
accept
the
default
user
of
sec_master.
A
prompt
appears
requesting
the
password
for
the
Tivoli
Access
Manager
administrator.
4.
Enter
the
password
for
sec_master.
A
series
of
status
messages
appear.
The
plug-in
for
Edge
Server
logs
in
to
the
Tivoli
Access
Manager
policy
server
and
unconfigures
itself.
The
unconfiguration
completes
and
the
wslconfig
utility
exits.
To
remove
the
plug-in
files
on
Linux,
enter
the
following
command:
rpm
-e
PDPlgES-PD
The
plug-in
for
Edge
Server
files
are
removed.
The
rpm
utility
exits.
Removal
of
the
plug-in
for
Edge
Server
on
Linux
is
complete.
Note:
You
may
find
that
the
unconfiguration
and
uninstallation
processes
do
not
fully
clean-up
the
plug-in
installation
directory.
To
completely
remove
the
product
run
the
command,
rm
-rf
/opt/pdweb-lite.
If
you
want
to
remove
the
Tivoli
Access
Manager
runtime
environment
or
other
Tivoli
Access
Manager
components,
follow
the
instructions
in
the
IBM
Tivoli
Access
Manager
Base
Installation
Guide.
Removing
the
plug-in
for
Edge
Server
on
Solaris
Removal
of
the
plug-in
for
Edge
Server
on
Solaris
is
a
two-part
process.
You
must
first
unconfigure
the
plug-in
package
and
then
remove
it.
To
unconfigure
the
plug-in
on
Solaris,
do
the
following:
1.
Log
in
as
root.
2.
Enter
the
following
command:
wslconfig.sh
-u
3.
Enter
the
user
ID
for
the
Tivoli
Access
Manager
administrative
user.
You
can
press
Enter
to
accept
the
default
user
of
sec_master.
A
prompt
appears
requesting
the
password
for
the
Tivoli
Access
Manager
administrator.
4.
Enter
the
password
for
sec_master.
A
series
of
status
messages
appear.
The
plug-in
for
Edge
Server
logs
in
to
the
Tivoli
Access
Manager
policy
server
and
unconfigures
itself.
The
unconfiguration
completes
and
the
wslconfig
utility
exits.
To
remove
the
plug-in
files
on
Solaris,
enter
the
following:
pkgrm
PDPlgES
66
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
The
plug-in
for
Edge
Server
files
are
removed.
The
pkgrm
utility
exits.
Removal
of
the
plug-in
for
Edge
Server
on
Solaris
is
complete.
Note:
You
may
find
that
the
unconfiguration
and
uninstallation
processes
do
not
fully
clean-up
the
plug-in
installation
directory.
To
completely
remove
the
product
run
the
command,
rm
-rf
/opt/pdweb-lite.
If
you
want
to
remove
the
Tivoli
Access
Manager
runtime
environment
or
other
Tivoli
Access
Manager
components,
follow
the
instructions
in
the
IBM
Tivoli
Access
Manager
Base
Installation
Guide.
Removing
the
plug-in
for
Edge
Server
on
Windows
Removal
of
the
plug-in
for
Edge
Server
on
Windows
is
a
two-part
process.
You
must
first
unconfigure
the
plug-in
package
and
then
remove
it.
To
unconfigure
the
plug-in
on
Windows,
do
the
following:
1.
Log
in
as
Administrator.
2.
Enter
the
following
command:
wslconfig
-u
3.
Enter
the
user
ID
for
the
Tivoli
Access
Manager
administrative
user.
You
can
press
Enter
to
accept
the
default
user
of
sec_master.
A
prompt
appears
requesting
the
password
for
the
Tivoli
Access
Manager
administrator.
4.
Enter
the
password
for
sec_master.
A
series
of
status
messages
appear.
The
plug-in
for
Edge
Server
logs
in
to
the
Tivoli
Access
Manager
policy
server
and
unconfigures
itself.
The
unconfiguration
completes
and
the
wslconfig
utility
exits.
To
remove
the
plug-in
files
on
Windows,
do
the
following:
1.
Select
Start
→
Settings
→
Control
Panel.
Click
Add/Remove
Programs.
The
Add/Remove
Programs
dialog
is
displayed,
listing
all
installed
software.
2.
Select
Tivoli
Access
Manager
Plug-in
for
Edge
Server.
Click
Add/Remove.
The
Choose
Language
Setup
dialog
is
displayed.
3.
Select
the
language
that
you
want
to
use
for
the
removal
process
and
click
OK.
4.
From
the
Confirm
Component
Removal
message
box,
click
Yes.
The
plug-in
for
Edge
Server
files
are
removed.
5.
Click
OK
to
exit
the
program.
Removal
of
the
plug-in
for
Edge
Server
on
Windows
is
complete.
If
you
want
to
remove
the
Tivoli
Access
Manager
runtime
environment
or
other
Tivoli
Access
Manager
components,
follow
the
instructions
in
the
IBM
Tivoli
Access
Manager
Base
Installation
Guide.
Chapter
8.
Removing
the
plug-in
for
Edge
Server
67
68
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Appendix
A.
Base
configuration
file
reference
The
ibmwesas.conf
file
contains
settings
used
to
initialize
the
plug-in.
These
settings
include
Tivoli
Access
Manager
configuration
settings
and
the
LTPA
&
WebSEAL
Fail
Over
cookie
module
configuration
settings.
Additional
configuration
is
available
through
the
object
space
definition
configuration
file.
Only
settings
requiring
user
modification
have
been
listed
in
the
following
table.
All
other
settings
are
properly
set
by
the
configuration
tool
and
generally
do
not
require
user
modification.
Option
Description
LTPA_Cookie_Enabled
Indicates
whether
the
LTPA
cookie
module
is
initialized
using
the
key
file
and
the
key
file
password.
The
default
value
is
no.
LTPA_Cookie_Keyfile
Indicates
the
LTPA
key
file
containing
the
cipher
keys
used
for
encryption
and
decryption.
This
file
can
be
generated
by
WebSphere
Application
Server
for
single
signon
between
the
plug-in
and
server.
LTPA_Cookie_Keyfile_Password
Indicates
the
password
needed
to
access
the
LTPA
key
file.
LTPA_Cookie_TTL
Indicates
the
idle
expiration
period
for
an
LTPA
cookie
that
is
not
refreshed
by
the
plug-in.
The
default
value
is
20
minutes.
LTPA_Cookie_Validation
Indicates
whether
an
LTPA
cookie’s
signature
is
validated
for
increased
security
when
the
plug-in
decrypts
the
cookie.
Note
that
this
validation
can
be
more
CPU
intensive
than
simply
decrypting
the
cookie.
The
default
value
is
yes.
WebSEAL_Cookie_Enabled
Indicates
whether
the
WebSEAL
Fail
Over
cookie
module
is
initialized
using
the
key
file
and
the
key
file
label.
The
default
value
is
no.
WebSEAL_Cookie_Keyfile
Indicates
the
WebSEAL
Fail
Over
cookie
key
file
containing
the
cipher
keys
used
for
encryption
and
decryption.
This
key
file
is
generated
during
the
configuration
of
the
plug-in.
WebSEAL_Cookie_Keylabel
Indicates
the
label
used
to
extract
the
cipher
keys
from
the
WebSEAL
Fail
Over
cookie
key
file.
WebSEAL_Cookie_TTL
Indicates
the
idle
expiration
period
for
a
WebSEAL
Fail
Over
cookie
that
is
not
refreshed
by
the
plug-in.
The
default
value
is
20
minutes.
ObjectSpace_File
Indicates
the
location
of
the
object
space
definition
configuration
file.
This
file
tells
the
plug-in
which
branch
of
the
Tivoli
Access
Manager
object
space
is
used
for
authorization,
based
on
the
domain
name
specified
in
the
URL.
This
file
also
specifies
domain
specific
configuration
settings.
©
Copyright
IBM
Corp.
2001,
2003
69
Option
Description
UserMap_File
Indicates
the
location
of
the
user
mapping
file.
This
file
tells
the
plug-in
how
to
map
a
generic
user
ID
or
certificate
distinguished
name
to
a
Tivoli
Access
Manager
user.
This
file
is
used
to
determine
credentials
for
certificate
users
and
users
who
are
authenticated
before
reaching
the
plug-in.
70
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Appendix
B.
Object
space
definition
configuration
file
reference
This
appendix
provides
reference
information
on
the
object
space
definition
configuration
file
and
includes
the
following
sections:
v
“Server
definitions”
v
“Single
signon
definitions”
on
page
81
Server
definitions
The
osdef.conf
file
defines
a
mapping
between
protected
objects
(URLs)
and
the
Tivoli
Access
Manager
object
space.
Settings
for
protected
Web
servers
are
organized
into
server
definitions.
Within
each
server
definition,
server
specific
settings
such
as
the
domain,
login
method,
the
branch
of
the
object
space
that
should
be
used
to
perform
authorization
checks
against
users,
and
other
domain
specific
settings
are
configured.
Option
Description
Object
space
(wesosm
only)
update_objectspace
Indicates
whether
this
instance
of
the
plug-in
is
responsible
for
updating
the
Tivoli
Access
Manager
object
space
with
each
Web
server’s
file
system
information.
The
default
value
is
yes.
update_admin_userid
Indicates
the
Tivoli
Access
Manager
administrator
user
ID
that
is
required
to
modify
the
object
space.
update_admin_password
Indicates
the
Tivoli
Access
Manager
administrator
password
that
is
required
to
modify
the
object
space.
query_command
Indicates
the
HTTP
request
issued
to
get
object
space
information.
The
format
of
the
data
returned
by
this
request
should
conform
to
the
WebSEAL
query_contents
utility.
query_authentication
Indicates
the
HTTP
authorization
header
parameter
passed
to
the
Web
server
hosting
query_contents.
If
this
option
is
not
specified,
no
authorization
header
is
sent.
query_interval
Indicates
the
rate
at
which
the
object
space
underneath
this
branch
is
updated.
If
the
value
is
set
to
0,
no
updates
are
performed
to
this
branch
of
the
Tivoli
Access
Manager
object
space.
The
default
value
is
1440
minutes
(1
day).
query_files
Indicates
whether
the
files
in
each
directory
are
also
queried
into
the
Tivoli
Access
Manager
object
space.
If
you
intend
to
attach
ACLs
only
to
directories,
then
there
is
no
need
for
Tivoli
Access
Manager
to
store
the
Web
files
in
the
object
space.
The
default
value
is
no.
©
Copyright
IBM
Corp.
2001,
2003
71
Option
Description
query_depth
Indicates
the
depth
of
subdirectories
that
is
queried
into
the
Tivoli
Access
Manager
object
space.
Since
the
object
space
is
stored
in
the
authorization
database,
it
is
beneficial
not
to
store
unnecessary
file
system
information
in
this
database.
It
is
sufficient
to
store
just
the
objects
in
the
Web
space
that
should
have
ACLs
attached
to
them.
Setting
this
value
to
0
disables
depth
constraints
for
this
branch
in
the
object
space.
The
default
value
is
0.
query_removal
Indicates
whether
unrecognized
or
unknown
entries
are
removed
from
the
object
space.
If
enabled,
all
existing
entries
underneath
this
branch
that
are
not
found
on
the
Web
server,
are
removed
from
the
object
space.
The
default
value
is
yes.
fix_absolute_urls
If
the
file
returned
by
a
protected
Web
server
does
not
use
relative
URL
links
when
referring
to
objects
on
the
same
server,
the
browser
is
misdirected
when
trying
access
another
object
on
the
same
server.
The
fix_absolute_urls
parameter
directs
the
Edge
Server
plug-in
to
replace
all
’/dir’
paths
with
’/junction_dir/dir’
on
subsequent
browser
requests.This
parameter
can
be
set
to:
v
use_referrer,
which
uses
the
object
path
to
create
the
URL
of
the
newly
accessed
object.
v
use_cookie,
which
uses
a
cookie
to
store
the
object
path
and
construct
the
URL
of
the
newly
accessed
object.
v
no,
which
disables
this
functionality.
The
default
value
is
use_referrer.
Object
space
(wesosm
and
plug-in)
objectspace_branch_reverse
Indicates
the
object
space
branch
under
which
authorization
requests
take
place
for
reverse
proxy
requests
not
explicitly
defined
in
this
file.
The
default
value
is
/reverse.
objectspace_branch_forward
Indicates
the
object
space
branch
under
which
authorization
requests
take
place
for
forward
proxy
requests
not
explicitly
defined
in
this
file.
The
default
value
is
/forward.
objectspace_filesystem_type
Indicates
the
type
of
file
system
that
the
content
Web
server
runs
on.
This
setting
determines
how
each
URL
is
mapped
to
an
ACL
string
to
authorize
the
user.
The
default
value
is
unix.
File
system
types:
v
unix
-
Case
sensitive
UNIX
file
system
v
win32
-
Case
insensitive
WIN32
file
system
General
72
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Option
Description
domains
Indicates
the
list
of
domains
for
which
a
server
definition
applies
to.
If
the
domain
name
in
a
requested
URL
matches
any
of
the
specified
domain
names,
then
the
configuration
settings
for
the
request
are
retrieved
from
that
server
definition.
login_method
Indicates
the
login
method
for
this
domain.
The
login
method
can
be
associated
with
a
specific
device
profile
(WebSphere
EveryPlace
Suite
only).
If
no
device
is
specified,
all
devices
use
the
same
login
method.
The
default
value
is
basic.
Login
methods:
v
none
-
The
user
is
not
required
to
login.
v
basic
-
The
user
logs
in
using
basic
authentication.
v
forms
-
The
user
logs
in
using
a
form.
v
certificate
-
The
user
logs
in
using
a
client
certificate.
Syntax:
login
method
[device
profile
list]
reverse_dns_lookup
If
a
URL
contains
an
IP
address
or
incomplete
domain
name,
this
option
tells
the
plug-in
to
perform
a
reverse
DNS
look
up
to
determine
the
fully
qualified
domain
name
and
make
authorization
decisions
based
on
the
expanded
name.
This
option
is
valid
only
in
the
[Global]
section
of
this
file.
The
default
value
is
yes.
User
information
realm
Indicates
the
realm
to
append
to
each
user
ID
before
authenticating
the
user.
For
example,
if
the
realm
is
bank_a,
then
user
joe
is
authenticated
as
joe@bank_a.
Since
Tivoli
Access
Manager
uses
a
single
name
space
for
all
user
IDs,
it
might
be
necessary
to
create
user
IDs
in
Tivoli
Access
Manager
with
realms
appended
to
them.
This
way,
identical
user
IDs
belonging
to
different
domains
can
coexist
in
Tivoli
Access
Manager’s
user
registry
(example:
joe@bank_a,
joe@bank_b).
Error
pages
require_ssl_errorfile
If
a
domain
requires
an
SSL
connection,
and
the
established
connection
is
not
SSL,
then
this
error
is
returned
to
the
user.
require_cert_errorfile
If
a
domain
requires
a
certificate,
and
one
is
not
provided
by
the
user’s
browser,
then
this
error
is
returned
to
the
user.
Form
login
Appendix
B.
Object
space
definition
configuration
file
reference
73
Option
Description
form_login_file
Indicates
the
form
login
file
used
for
authentication.
This
file
can
exist
locally,
or
exist
as
a
remote
file
specified
in
a
URL.
If
this
option
is
unspecified,
then
form
login
is
not
used
for
this
domain.
Form
login
can
be
associated
with
a
specific
device
profile.
If
no
device
is
specified,
then
all
devices
will
use
the
same
form.
Syntax:
local
path
|
URL
[device
profile
list]
form_login_errorfile
Indicates
the
form
error
file
sent
when
a
user
fails
form
authentication.
This
file
can
be
identical
to
the
login
file
with
the
exception
of
an
error
message
indicating
that
the
user
failed
to
login.
Syntax:
local
path
|
URL
[device
profile
list]
form_logout_file
Indicates
the
form
logout
file
sent
when
a
user
submits
the
logout
URL.
This
file
can
contain
a
message
telling
the
user
that
the
session
has
ended.
If
unspecified,
the
request
passes
through
to
the
backend
server.
Syntax:
local
path
|
URL
[device
profile
list]
form_type
Indicates
the
form
MIME
content
type,
specifying
the
format
of
the
form
file.
A
special
type
can
be
required
for
wireless
devices.
If
no
type
is
specified,
then
text/html
is
assumed.
Syntax:
type
[device
profile
list]
form_signature_login
A
form
signature
is
a
hidden
attribute
to
value
assignment
in
a
form.
If
the
plug-in
receives
a
form
submission
that
includes
this
assignment
when
forms
is
selected
as
the
login
method,
it
extracts
the
user
ID
and
password
from
the
form
to
authenticate
the
user.
Using
this
method
for
form
login,
the
plug-in
can
authenticate
a
user
even
if
the
user
had
not
previously
tried
to
access
a
protected
Web
page.
Note
that
if
this
option
is
specified,
the
signature
must
be
found
in
the
form,
otherwise
if
unspecified,
no
form
signature
is
checked.
Syntax:
name=value
74
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Option
Description
form_login_url
Indicates
the
form
login
URL
where
the
user
submits
authentication
form.
If
the
plug-in
receives
a
form
submission
that
matches
this
URL
when
forms
is
selected
as
the
login
method,
then
it
extracts
the
user
ID
and
password
from
the
form
to
authenticate
the
user.
Note
that
configuring
the
form
login
signature
is
another
method
for
the
plug-in
to
detect
the
submission
of
a
login
form.
If
neither
the
form_login_url
nor
the
form_signature_login
options
are
configured,
then
the
plug-in
uses
a
cookie
to
detect
the
submission
of
the
login
form.
Syntax:
URL
[device
profile
list]
form_logout_url
Indicates
the
form
logout
URL
submitted
by
the
user
to
logout.
The
plug-in
deletes
the
user’s
session
information
when
the
user
makes
a
request
that
matches
this
URL.
Syntax:
URL
[device
profile
list]
form_login_url_recovery
Indicates
whether
the
plug-in
redirects
the
browser
to
the
original
URL
after
authentication
when
the
user
authenticates
using
the
form
login
URL.
The
default
value
is
yes.
form_session_size
Indicates
the
maximum
number
of
users
that
can
be
simultaneously
logged
in
using
form
login.
This
option
is
valid
only
in
the
[Global]
section
of
this
file.
The
default
value
is
10000
users.
form_session_timeout
Indicates
the
amount
of
time
that
a
user
can
remain
idle
and
not
submit
a
request
when
logged
in
using
form
login.
After
this
timeout
period,
the
user
is
required
to
login
again.
The
default
value
is
20
minutes.
form_ssl_security
Indicates
the
type
of
security
used
for
secure
form
login.
When
form
login
is
used
over
a
secure
connection,
the
user
ID
and
password
is
stored
locally
and
associated
with
a
secure
session
ID.
The
default
value
is
cookie_sessionId.
Form
login
security
options:
v
ssl_sessionId
-
The
SSL
session
ID
is
associated
with
the
user
ID
and
password.
v
cookie_sessionId
-
A
transient
undecipherable
value,
stored
in
a
session
cookie,
is
associated
with
the
user
ID
and
password.
form_client_validation
Indicates
whether
a
user’s
IP
address
is
allowed
to
change
when
the
user
authenticates
using
form
login.
If
enabled,
the
user’s
IP
address
is
verified
for
the
duration
of
the
form
login
session.
The
default
value
is
yes.
Appendix
B.
Object
space
definition
configuration
file
reference
75
Option
Description
form_fieldname_userid
Indicates
the
field
name
of
the
user
ID
data
submitted
by
the
POST
operation.
The
default
value
is
UserID.
form_fieldname_password
Indicates
the
field
name
of
the
password
data
submitted
by
the
POST
operation.
This
setting
applies
to
both
the
login
and
change
password
form.
The
default
value
is
Password.
form_fieldname_newpassword
Indicates
the
field
name
of
the
new
password
data
submitted
by
the
POST
operation
when
the
user’s
password
is
changed.
The
default
value
is
NewPassword.
form_fieldname_verifynewpassword
Indicates
the
field
name
of
the
new
password
verification
data
submitted
by
the
POST
operation
when
the
user’s
password
is
changed.
The
default
value
is
VerifyNewPassword.
form_fieldname_requestdata
Indicates
the
hidden
field
name
in
the
authentication
form
which
stores
request
information.
The
plug-in
retrieves
request
information
from
this
field
when
a
form
is
submitted
for
authentication.
The
default
value
is
RequestData.
form_fieldvalue_requestdata
Indicates
the
hidden
field
value
in
the
authentication
form
which
the
plug-in
replaces
with
request
information.
The
plug-in
replaces
this
value
with
the
request
information
when
an
authentication
form
is
returned
to
a
user.
The
default
value
is
INSERT.REQUEST.DATA.HERE.
form_fieldname_postdata
Indicates
the
hidden
field
name
in
authentication
form
which
stores
contents
of
saved
POST
data.
The
plug-in
retrieves
saved
POST
data
from
this
field
when
a
form
is
submitted
for
authentication.
The
default
value
is
PostCacheData.
form_fieldvalue_postdata
Indicates
hidden
field
value
in
authentication
form,
which
the
plug-in
replaces
with
POST
data.
The
plug-in
replaces
this
value
with
the
submitted
POST
data
when
an
authentication
form
is
returned
to
a
user
who
submits
a
POST
request.
The
default
value
is
INSERT.POST.DATA.HERE.
form_fieldvalue_url
Indicates
a
hidden
field
value
in
the
authentication
form
which
the
plug-in
replaces
with
the
URL.
The
default
value
is
INSERT.URL.HERE.
form_fieldvalue_secure_url
Indicates
a
hidden
field
value
in
the
authentication
form
which
the
plug-in
replaces
with
the
secure
URL.
The
default
value
is
INSERT.SECURE.URL.HERE.
form_fieldvalue_method
Indicates
a
hidden
field
value
in
the
authentication
form
which
the
plug-in
replaces
with
the
method.
The
default
value
is
INSERT.METHOD.HERE.
76
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Option
Description
Change
password
form_chgpasswd_file
Indicates
the
form
sent
to
the
user
to
change
an
expired
password
when
the
login
method
is
basic
or
forms.
When
a
user’s
password
expires,
this
form
is
sent
to
the
user
to
change
the
expired
password.
If
this
option
is
unspecified,
no
password
expiration
check
is
performed.
Syntax:
local
path
|
URL
form_chgpasswd_generic_errorfile
Indicates
the
error
file
sent
to
the
user
specifying
that
a
generic
error
occurred
while
the
user’s
password
was
being
changed.
Syntax:
local
path
|
URL
form_chgpasswd_oldpasswd_errorfile
Indicates
the
error
file
sent
to
the
user
specifying
that
the
old
password
was
not
correct.
Syntax:
local
path
|
URL
form_chgpasswd_newpasswd_errorfile
Indicates
the
error
file
sent
to
the
user
specifying
that
the
new
password
failed
the
password
policy
validation
check.
Syntax:
local
path
|
URL
form_chgpasswd_verifypasswd_errorfile
Indicates
the
error
file
sent
to
the
user
specifying
that
the
new
password
was
incorrectly
verified
by
the
user.
Syntax:
local
path
|
URL
form_signature_chgpasswd
Indicates
the
form
signature
used
to
detect
the
submission
of
a
change
password
form.
If
the
plug-in
receives
a
form
submission
that
includes
this
signature,
then
it
extracts
the
user
information
from
the
form
to
change
the
user’s
password.
form_chgpasswd_submit_url
Indicates
the
URL
where
password
change
requests
are
submitted.
When
a
password
change
request
is
submitted
to
this
URL,
the
plug-in
updates
the
user’s
password
with
the
submitted
information.
A
user
must
already
be
authenticated
before
the
plug-in
changes
the
user’s
password.
Note
that
configuring
the
form
change
password
signature
is
another
method
for
the
plug-in
to
detect
the
submission
of
a
change
password
form.
This
feature
is
supported
only
for
the
Tivoli
Access
Manager
user
registry.
Syntax:
URL
[device
profile
list]
Appendix
B.
Object
space
definition
configuration
file
reference
77
Option
Description
form_chgpasswd_response_url
Indicates
the
response
URL
sent
to
the
user
when
the
password
is
changed
successfully.
This
page
tells
the
user
that
the
password
has
successfully
been
changed.
The
default
value
is
/.
Syntax:
URL
form_chgpasswd_url_recovery
Indicates
whether
the
plug-in
redirects
the
browser
to
the
original
URL
after
a
user
changes
an
expired
password,
rather
than
redirecting
the
browser
to
the
response
URL.
The
default
value
is
yes.
Security
cookie_security_enabled
Indicates
whether
cookies
created
over
a
secure
connection
are
allowed
to
flow
over
non-secure
connections.
If
enabled,
secure
cookies
are
not
allowed
to
flow
over
non-secure
connections.
The
default
value
is
yes.
require_ssl
Indicates
whether
a
secure
connection
is
required
to
access
this
domain.
If
a
secure
connection
is
required,
the
browser
is
automatically
redirected
to
the
secure
site.
Single
signon
accept_sso
Indicates
single
signon
tokens
to
accept
for
this
domain.
The
plug-in
can
skip
authentication
if
the
user
has
already
been
authenticated.
The
plug-in
searches
this
list
until
it
finds
a
single
signon
token.
See
the
SSO
section
for
more
information
on
single
signon.
submit_sso
Indicates
single
signon
tokens
to
submit
for
this
domain.
The
plug-in
can
submit
an
authenticated
user’s
information
to
the
backend
server.
The
plug-in
submits
each
single
signon
token
in
the
list
to
the
backend
server.
See
the
SSO
section
for
more
information
on
single
signon.
Cross
Domain
Single
Signon
cdsso_loaded
Indicates
whether
the
cross
domain
single
signon
module
is
loaded
and
initialized.
This
option
is
valid
only
in
the
[Global]
stanza.
The
default
value
is
no.
cdsso_enabled
Indicates
whether
cross
domain
single
signon
is
enabled
for
this
server.
The
default
value
is
no.
cdsso_link_url
Indicates
the
URL
used
to
perform
cross
domain
single
signon
using
an
embedded
URL
link.
The
default
value
is
/pkmscdsso.
cdsso_link_argument
Indicates
the
name
of
the
argument
in
the
URL
containing
the
encrypted
token
for
cross
domain
single
signon
using
an
embedded
URL
link.
The
default
value
is
PD-ID.
78
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Option
Description
cdsso_ecom_vouch_url
Indicates
the
URL
is
used
to
perform
eCommunity
cross
domain
single
signon.
The
default
value
is
/pkmsvouchfor.
cdsso_ecom_vouch_argument
Indicates
the
name
of
the
argument
in
the
URL
that
will
contain
the
encrypted
token
for
eCommunity
cross
domain
single
signon.
The
default
value
is
PD-VF.
cdsso_group
Indicates
the
cross
domain
single
signon
definition
associated
with
this
server.
If
unspecified,
cross
domain
single
signon
remains
disabled
for
this
server.
cdsso_keyfile
Indicates
the
key
file
used
to
encrypt
and
decrypt
tokens
for
this
server.
If
specified,
the
domain
is
associated
with
the
key
file,
otherwise,
the
key
file
applies
to
all
domains.
There
may
be
multiple
instances
of
this
setting.
Routing
route
Indicates
the
destination
server
to
forward
the
request
in
reverse
proxy
configurations.
In
this
configuration,
DNS
is
configured
to
map
multiple
domain
names
to
the
plug-in.
The
route
option
tells
the
plug-in
to
route
the
request
to
the
corresponding
content
Web
server.
If
no
route
option
is
specified
in
this
configuration,
the
caching
proxy
routes
the
request
using
its
configured
mapping
rules.
Syntax:
URL
[default
page]
proxy
Indicates
the
URL
of
the
HTTP
proxy
server
that
all
requests
are
proxied
through.
For
example,
a
transcoder
proxy
server
can
be
used
to
convert
HTML
files
into
device
compatible
files.
This
option
is
applicable
only
when
the
request
is
routed.
Syntax:
URL
Caching
user_cache_size
Indicates
the
maximum
number
of
users
that
are
stored
in
the
cache
table
for
authenticated
users.
When
a
user
authenticates
successfully,
the
user’s
credentials
are
stored
in
this
cache.
On
subsequent
requests
by
the
same
user,
the
user’s
credentials
are
retrieved
from
this
cache.
After
this
time
elapses,
the
user’s
credentials
are
verified
against
the
user
registry.
This
option
is
valid
only
in
the
[Global]
section
of
this
file.
The
default
value
is
20000.
When
WES
support
is
enabled,
set
the
MaxSessionCache
parameter
in
ibmwesas.conf
instead.
Appendix
B.
Object
space
definition
configuration
file
reference
79
Option
Description
user_cache_timeout
Indicates
the
maximum
amount
of
time
that
an
authenticated
user
is
stored
in
the
cache.
After
the
specified
time,
the
user’s
cached
credentials
are
verified
against
the
user
registry.
If
verification
fails,
the
user
is
required
to
login
again.
The
default
value
is
10
minutes.
When
WES
support
is
enabled,
set
the
MaxSessionAge
parameter
in
ibmwesas.conf
instead.
Logging
logging_flags
Indicates
the
category
of
logging
messages
that
the
plug-in
sends
to
the
event
log
file.
Only
messages
matching
the
specified
category
are
sent
to
the
log
file.
This
option
is
valid
only
in
the
[Global]
section
of
this
file.
The
default
value
is
EWI.
Log
message
flag
options:
v
E
-
Error
messages
v
W
-
Warning
messages
v
I
-
Informational
messages
v
D
-
Debugging
messages
logging_level
Indicates
the
verbosity
level
for
informational
and
debugging
log
messages.
This
value
can
range
from
0
to
5.
A
higher
number
means
that
more
messages
are
logged.
This
option
is
valid
only
in
the
[Global]
section
of
this
file.
The
default
value
is
3.
CDAS
support
cdas_loaded
Indicates
whether
the
CDAS
module
is
loaded
and
initialized.
This
option
is
valid
only
in
the
[Global]
section
of
this
file.
The
default
value
is
no.
cdas_init_parameter
Indicates
the
initialization
parameters
that
are
passed
to
the
CDAS
module.
The
CDAS
initialization
function
is
called
multiple
times
if
multiple
entries
are
defined.
This
option
is
valid
only
in
the
[Global]
section
of
this
file.
cdas_enabled
Indicates
whether
the
CDAS
module
is
invoked
when
the
login
method
is
basic,
forms,
or
certificate.
Using
this
option,
CDAS
can
be
enabled
for
some
URLs
and
disabled
for
others.
Note
that
CDAS
does
not
need
to
be
enabled
for
single
signon
support.
The
default
value
is
no.
cdas_tagvalue_enabled
Indicates
whether
the
CDAS
module
is
invoked
simply
to
add
extended
attributes
to
the
user’s
credential,
when
the
Tivoli
Access
Manager
user
registry
is
used
for
authentication.
Using
this
option,
the
plug-in
performs
the
authentication
but
invokes
the
CDAS
module
to
add
the
extended
user
attributes.
The
default
value
is
no.
80
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Option
Description
cdas_auth_parameter
Indicates
the
correlating
parameters
that
are
passed
to
the
CDAS
module
for
all
requests
matching
the
server
definition
in
the
configuration
file.
Using
this
option,
the
CDAS
module
can
choose
the
authentication
method
based
on
this
parameter.
There
is
no
default
value.
cdas_sso_headers
Indicates
whether
HTTP
headers
are
generated
for
each
extended
attribute
returned
from
the
CDAS
authentication
module.
If
enabled,
an
HTTP
header
is
generated
for
each
name/value
pair
in
the
extended
attribute
list
that
has
a
name
of
the
format,
tagvalue_name.
The
generated
HTTP
header
is
formatted
according
to
the
setting
of
the
tagvalue_creds_headers
option.
The
default
value
is
yes.
cdas_sso_mapping
Indicates
whether
the
corresponding
Tivoli
Access
Manager
user
ID
is
submitted
for
single
signon
to
the
backend
server.
If
disabled,
the
original
CDAS
user
ID
is
submitted
for
single
signon.
The
default
value
is
yes.
Tag-value
tagvalue_creds_registry
Indicates
the
LDAP
attributes
that
are
added
to
the
user’s
credentials
after
authentication.
There
might
be
multiple
instances
of
this
setting.
If
unspecified,
no
LDAP
attributes
are
added
to
the
user’s
credentials.
Syntax:
credential
attribute
name:ldap
attribute
name
tagvalue_creds_headers
Indicates
the
tag-value
credential
attributes
that
are
added
to
the
HTTP
headers
destined
for
the
backend
server.
There
might
be
multiple
instances
of
this
setting.
If
the
special
character,
*
,
is
specified,
then
all
tag-value
credential
attributes
are
added
to
the
HTTP
headers
using
the
credential
attribute
name
as
the
HTTP
header
name.
Note
that
this
setting
also
applies
to
CDAS
extended
attributes.
Syntax:
credential
attribute
name:HTTP
header
name
Single
signon
definitions
The
plug-in
can
skip
the
authentication
step
if
a
user
has
already
been
authenticated.
The
plug-in
can
also
pass
single
signon
information
to
a
Web
server
either
as
an
HTTP
header
or
a
cookie.
The
plug-in
only
accepts
pre-authenticated
users
from
authentication
servers
that
are
trusted.
The
following
single
signon
definitions
are
predefined
and
can
be
used
as
parameters
to
accept_sso
and
submit_sso:
v
CDAS-MODULE:
CDAS
Module
Single
Signon
(SSO
accept
only)
Appendix
B.
Object
space
definition
configuration
file
reference
81
v
LTPA-COOKIE:
WebSphere
LTPA
Cookie
v
WEBSEAL-COOKIE:
WebSEAL’s
Fail
Over
Cookie
Option
Description
type
Indicates
single
signon
type:
v
cookie
-
Cookie
header
v
header
-
HTTP
header
v
auth_header
-
Authorization
header
(SSO
submit
only)
v
IP_address
-
IP
address
(SSO
accept
only)
name
Indicates
the
name
of
the
cookie
or
HTTP
header
that
contains
the
user’s
SSO
information.
This
option
defaults
to
Authorization
for
SSO
types
of
auth_header
and
is
not
applicable
for
SSO
types
of
IP_address.
format
Indicates
the
format
of
the
cookie
or
header
value.
The
following
macros
listed
can
be
used
to
specify
the
location
of
the
user
ID
in
the
header
or
cookie.
This
option
is
not
applicable
for
SSO
types
of
IP_address.
The
following
predefined
macros
can
be
used
to
format
the
single
signon
information:
v
<userid>
-
User’s
ID
v
<userdn>
-
User’s
Tivoli
Access
Manager
distinguished
name
v
<pd_cred>
-
User’s
Tivoli
Access
Manager
EPAC
credentials
(SSO
submit
only)
v
<opaque>
-
Data
not
recognized
by
the
plug-in
(SSO
accept
only)
sso_realm
Indicates
the
realm
appended
to
the
pre-authenticated
user
ID
using
this
single
signon
definition,
before
the
user
ID
is
mapped
to
a
Tivoli
Access
Manager
distinguished
name.
The
purpose
of
this
realm
is
to
uniquely
identify
a
mapping
rule
for
all
user
IDs
from
this
pre-authentication
server.
See
the
user
mapping
file
for
more
information.
This
option
is
not
applicable
when
SSO
information
is
submitted.
default_user
Indicates
the
default
Tivoli
Access
Manager
user
whose
credentials
are
used
to
authorize
users
who
have
already
been
authenticated
using
this
single
signon
definition.
If
a
mapping
entry
is
not
found
for
a
pre-authenticated
user
ID,
then
the
credentials
for
this
user
are
used
to
perform
the
authorization.
If
a
mapping
entry
is
not
found
for
a
pre-authenticated
user
ID
and
this
option
is
not
specified,
then
the
plug-in
directs
Tivoli
Access
Manager
to
lookup
the
user
ID
in
the
registry.
This
option
is
not
applicable
when
SSO
information
is
submitted.
82
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Option
Description
trust_basis
Indicates
the
basis
on
which
the
plug-in
can
trust
the
pre-authentication
server.
The
plug-in
accepts
a
pre-authenticated
user
only
if
the
pre-authentication
server
is
trusted
by
the
plug-in.
The
default
value
is
IP_address.
This
option
is
not
applicable
when
SSO
information
is
submitted.
Trust
basis
options:
v
IP_address
-
The
IP
address
of
the
pre-authentication
server
must
match
an
entry
in
the
trust_list
setting.
If
no
IP
address
is
specified
for
the
trust_list,
then
no
pre-authenticated
users
are
accepted
using
this
single
signon
definition.
v
basic_auth
-
The
pre-authentication
server
must
authenticate
using
an
Authorization
header.
The
user
ID
and
password
submitted
must
match
an
entry
in
the
trust_list
setting.
v
proxy_auth
-
The
pre-authentication
server
must
authenticate
using
a
Proxy-Authorization
header.
The
user
ID
and
password
submitted
must
match
an
entry
in
the
trust_list
setting.
v
certificate
-
The
pre-authentication
server
must
authenticate
using
a
client
certificate.
The
certificate
DN
must
match
an
entry
in
the
trust_list
setting.
trust_list
Indicates
the
list
of
acceptable
identifications
that
can
be
presented
to
the
plug-in
by
the
pre-authentication
server.
This
option
is
not
applicable
when
SSO
information
is
submitted.
Cross
domain
single
signon
definitions
Option
Description
type
Indicates
cross
domain
single
signon
configuration
type.
Valid
values
are:
v
CDSSO
–
Cross
domain
single
signon
using
an
embedded
URL
link.
v
ECSSO
–
Cross
domain
single
signon
using
eCommunity
master
authentication
server.
ecom_community
Indicates
the
eCommunity
name
when
the
configuration
type
is
ECSSO.
ecom_master_server
Indicates
the
domain
name
of
the
master
authentication
server
when
the
configuration
type
is
ECSSO.
ecom_vouch_lifetime
Indicates
the
lifetime
of
the
eCommunity
domain
cookie
created
by
the
server
that
will
vouch
for
other
servers
within
the
domain
when
the
configuration
type
is
ECSSO.
The
default
value
is
300
minutes.
session_lifetime
Indicates
the
lifetime
of
the
user
session
created
by
each
server
that
authenticates
a
user
through
cross
domain
single
signon.
The
default
value
is
20
minutes.
Appendix
B.
Object
space
definition
configuration
file
reference
83
Option
Description
token_security
Indicates
the
level
of
security
used
to
encrypt
the
authentication
token
that
passes
encrypted
user
information
to
another
domain.
The
default
value
is
privacy.
Token
security
options:
v
privacy
–
Token
information
is
encrypted
to
ensure
privacy.
v
privacy_integrity
–
Token
information
is
encrypted
and
signed
to
ensure
privacy
and
integrity.
token_lifetime
Indicates
the
lifetime
of
the
authentication
token
used
to
pass
encrypted
user
information
to
another
domain.
The
default
value
is
180
seconds.
84
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Appendix
C.
Command
reference
©
Copyright
IBM
Corp.
2001,
2003
85
wesosm
Creates
and
maintains
the
Tivoli
Access
Manager
object
space
for
the
Edge
Server
plug-in.
Syntax
wesosm
–start
[–infile
input_file]
[–logging
[log_file]
[–clean][–force
[
branch]]
[–fast]
wesosm
–stop
[–infile
input_file]
[–logging
[log_file]
[–clean][–force
[
branch]]
[–fast]
wesosm
–run
[–infile
input_file]
[–logging
[log_file]
[–clean][–force
[
branch]]
[–fast]
wesosm
–file
[–infile
input_file]
[–logging
[log_file]
[–clean][–force
[
branch]]
[–fast]
wesosm
–skiperrors
wesosm
–verbose
Parameters
–clean
Removes
all
entries
from
the
object
space
underneath
/ESproxy,
which
are
not
found
in
the
configuration
file,
osdef.conf.
Be
careful
when
using
this
option
because
any
attached
ACLs
are
lost
when
object
space
entries
are
deleted.
–fast
Compares
only
the
object
names
and
does
not
compare
the
types
when
checking
for
differences
between
the
Tivoli
Access
Manager
object
space
and
the
Web
server’s
file
system.
The
Tivoli
Access
Manager
object
type
indicates
whether
the
object
space
entry
is
a
file
or
directory.
For
example,
if
an
existing
file
on
the
Web
server
is
changed
to
a
directory
but
the
name
remains
the
same,
the
utility
does
not
detect
this
when
this
parameter
is
specified.
–file
[output_file]
Starts
the
object
space
manager
to
update
the
object
space
once
and
then
terminates
the
utility.
Rather
than
updating
the
Tivoli
Access
Manager
object
space,
the
object
space
information
is
written
to
the
specified
file.
–force
[branch]
Forces
the
utility
to
initially
update
the
object
space,
before
waiting
on
an
interval
for
the
next
update,
when
starting
the
object
space
manager
as
a
daemon.
If
specified,
only
the
indicated
branch
in
the
object
space
is
updated.
Wild
cards
can
be
used
to
specify
the
branch.
–infile
input_file
Indicates
the
location
of
the
configuration
file,
osdef.conf,
that
is
used
to
update
the
object
space.
–logging
[log_file]
Indicates
if
the
object
space
manager
should
log
object
space
updates
to
a
log
file.
If
no
log
file
is
specified,
the
default
log
file
wesosm.log
is
used.
–run
Starts
the
object
space
manager
to
update
the
object
space
once
and
then
terminates
the
utility.
86
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
–skiperrors
Does
not
terminate
if
it
encounters
an
error
updating
the
Tivoli
Access
Manager
object
space
when
updating
the
object
space.
This
is
useful
if
the
object
space
contains
invalid
entries
in
it.
–start
Starts
the
object
space
manager
as
a
daemon.
The
daemon
installs
itself
in
memory
to
update
the
object
space
on
intervals,
as
configured
in
the
osdef.conf
configuration
file.
This
ensures
that
the
object
space
is
kept
in
synchronization
with
the
content
on
the
corresponding
Web
server.
–stop
Stops
the
object
space
manager
daemon.
The
daemon
removes
itself
from
memory
and
ceases
to
perform
further
updates
to
the
object
space.
–verbose
When
updating
the
object
space,
displays
information
about
the
exact
entries
that
are
created,
deleted,
and
modified
in
the
object
space.
Availability
This
command
is
located
in
the
following
default
installation
directories:
v
UNIX
systems:
/opt/pdweb-lite/bin/
v
On
Windows
systems:
C:\Program
Files\Tivoli\pdweb-lite\bin\
When
an
installation
directory
other
than
the
default
is
selected,
this
utility
is
located
in
the
bin
directory
under
the
installation
directory
(for
example,
install_dir\bin\).
Return
Codes
The
following
exit
status
codes
can
be
returned:
0
The
command
completed
successfully.
1
The
command
failed.
When
the
command
fails,
an
error
message
is
displayed.
Refer
to
the
IBM
Tivoli
Access
Manager
Error
Message
Reference
for
a
more
detailed
description
of
the
problem.
Appendix
C.
Command
reference
87
wslstartwte
Manually
starts
the
Edge
Server
caching
proxy
and
loads
the
plug-in
for
Edge
Server
on
UNIX.
Syntax
wslstartwte
Parameters
None.
Comments
To
start
the
plug-in
for
Edge
Server
on
Windows,
use
the
IBM
Caching
proxy
service.
Availability
This
command
is
located
in
the
following
default
installation
directories:
v
UNIX
systems:
/opt/pdweb-lite/bin/
v
On
Windows
systems:
C:\Program
Files\Tivoli\pdweb-lite\bin\
When
an
installation
directory
other
than
the
default
is
selected,
this
utility
is
located
in
the
bin
directory
under
the
installation
directory
(for
example,
install_dir\bin\).
Return
Codes
The
following
exit
status
codes
can
be
returned:
0
The
command
completed
successfully.
1
The
command
failed.
When
the
command
fails,
an
error
message
is
displayed.
Refer
to
the
IBM
Tivoli
Access
Manager
Error
Message
Reference
for
a
more
detailed
description
of
the
problem.
88
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
wslstopwte
Stops
the
Edge
Server
caching
proxy
on
UNIX
systems.
Syntax
wslstopwte
Parameters
None.
Comments
To
stop
the
plug-in
for
Edge
Server
on
Windows,
use
the
IBM
Caching
proxy
service.
Availability
This
command
is
located
in
the
following
default
installation
directories:
v
UNIX
systems:
/opt/pdweb-lite/bin/
v
On
Windows
systems:
C:\Program
Files\Tivoli\pdweb-lite\bin\
When
an
installation
directory
other
than
the
default
is
selected,
this
utility
is
located
in
the
bin
directory
under
the
installation
directory
(for
example,
install_dir\bin\).
Return
Codes
The
following
exit
status
codes
can
be
returned:
0
The
command
completed
successfully.
1
The
command
failed.
When
the
command
fails,
an
error
message
is
displayed.
Refer
to
the
IBM
Tivoli
Access
Manager
Error
Message
Reference
for
a
more
detailed
description
of
the
problem.
Appendix
C.
Command
reference
89
90
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Appendix
D.
Notices
This
information
was
developed
for
products
and
services
offered
in
the
U.S.A.
IBM
may
not
offer
the
products,
services,
or
features
discussed
in
this
document
in
other
countries.
Consult
your
local
IBM
representative
for
information
on
the
products
and
services
currently
available
in
your
area.
Any
reference
to
an
IBM
product,
program,
or
service
is
not
intended
to
state
or
imply
that
only
that
IBM
product,
program,
or
service
may
be
used.
Any
functionally
equivalent
product,
program,
or
service
that
does
not
infringe
any
IBM
intellectual
property
right
may
be
used
instead.
However,
it
is
the
user’s
responsibility
to
evaluate
and
verify
the
operation
of
any
non-IBM
product,
program,
or
service.
IBM
may
have
patents
or
pending
patent
applications
covering
subject
matter
described
in
this
document.
The
furnishing
of
this
document
does
not
give
you
any
license
to
these
patents.
You
can
send
license
inquiries,
in
writing,
to:
IBM
Director
of
Licensing
IBM
Corporation
North
Castle
Drive
Armonk,
NY
10504-1785
U.S.A.
For
license
inquiries
regarding
double-byte
(DBCS)
information,
contact
the
IBM
Intellectual
Property
Department
in
your
country
or
send
inquiries,
in
writing,
to:
IBM
World
Trade
Asia
Corporation
Licensing
2-31
Roppongi
3-chome,
Minato-ku
Tokyo
106,
Japan
The
following
paragraph
does
not
apply
to
the
United
Kingdom
or
any
other
country
where
such
provisions
are
inconsistent
with
local
law:
INTERNATIONAL
BUSINESS
MACHINES
CORPORATION
PROVIDES
THIS
PUBLICATION
″AS
IS″
WITHOUT
WARRANTY
OF
ANY
KIND,
EITHER
EXPRESS
OR
IMPLIED,
INCLUDING,
BUT
NOT
LIMITED
TO,
THE
IMPLIED
WARRANTIES
OF
NON-INFRINGEMENT,
MERCHANTABILITY
OR
FITNESS
FOR
A
PARTICULAR
PURPOSE.
Some
states
do
not
allow
disclaimer
of
express
or
implied
warranties
in
certain
transactions,
therefore,
this
statement
may
not
apply
to
you.
This
information
could
include
technical
inaccuracies
or
typographical
errors.
Changes
are
periodically
made
to
the
information
herein;
these
changes
will
be
incorporated
in
new
editions
of
the
publication.
IBM
may
make
improvements
and/or
changes
in
the
product(s)
and/or
the
program(s)
described
in
this
publication
at
any
time
without
notice.
Any
references
in
this
information
to
non-IBM
Web
sites
are
provided
for
convenience
only
and
do
not
in
any
manner
serve
as
an
endorsement
of
those
Web
sites.
The
materials
at
those
Web
sites
are
not
part
of
the
materials
for
this
IBM
product
and
use
of
those
Web
sites
is
at
your
own
risk.
IBM
may
use
or
distribute
any
of
the
information
you
supply
in
any
way
it
believes
appropriate
without
incurring
any
obligation
to
you.
©
Copyright
IBM
Corp.
2001,
2003
91
Licensees
of
this
program
who
wish
to
have
information
about
it
for
the
purpose
of
enabling:
(i)
the
exchange
of
information
between
independently
created
programs
and
other
programs
(including
this
one)
and
(ii)
the
mutual
use
of
the
information
which
has
been
exchanged,
should
contact:
IBM
Corporation
2Z4A/101
11400
Burnet
Road
Austin,
TX
78758
U.S.A.
Such
information
may
be
available,
subject
to
appropriate
terms
and
conditions,
including
in
some
cases,
payment
of
a
fee.
The
licensed
program
described
in
this
document
and
all
licensed
material
available
for
it
are
provided
by
IBM
under
terms
of
the
IBM
Customer
Agreement,
IBM
International
Program
License
Agreement
or
any
equivalent
agreement
between
us.
Information
concerning
non-IBM
products
was
obtained
from
the
suppliers
of
those
products,
their
published
announcements
or
other
publicly
available
sources.
IBM
has
not
tested
those
products
and
cannot
confirm
the
accuracy
of
performance,
compatibility
or
any
other
claims
related
to
non-IBM
products.
Questions
on
the
capabilities
of
non-IBM
products
should
be
addressed
to
the
suppliers
of
those
products.
All
statements
regarding
IBM’s
future
direction
or
intent
are
subject
to
change
or
withdrawal
without
notice,
and
represent
goals
and
objectives
only.
This
information
contains
examples
of
data
and
reports
used
in
daily
business
operations.
To
illustrate
them
as
completely
as
possible,
the
examples
include
the
names
of
individuals,
companies,
brands,
and
products.
All
of
these
names
are
fictitious
and
any
similarity
to
the
names
and
addresses
used
by
an
actual
business
enterprise
is
entirely
coincidental.
COPYRIGHT
LICENSE:
This
information
contains
sample
application
programs
in
source
language,
which
illustrates
programming
techniques
on
various
operating
platforms.
You
may
copy,
modify,
and
distribute
these
sample
programs
in
any
form
without
payment
to
IBM,
for
the
purposes
of
developing,
using,
marketing
or
distributing
application
programs
conforming
to
the
application
programming
interface
for
the
operating
platform
for
which
the
sample
programs
are
written.
These
examples
have
not
been
thoroughly
tested
under
all
conditions.
IBM,
therefore,
cannot
guarantee
or
imply
reliability,
serviceability,
or
function
of
these
programs.
You
may
copy,
modify,
and
distribute
these
sample
programs
in
any
form
without
payment
to
IBM
for
the
purposes
of
developing,
using,
marketing,
or
distributing
application
programs
conforming
to
IBM’s
application
programming
interfaces.
Each
copy
or
any
portion
of
these
sample
programs
or
any
derivative
work,
must
include
a
copyright
notice
as
follows:
©
(your
company
name)
(year).
Portions
of
this
code
are
derived
from
IBM
Corp.
Sample
Programs.
©
Copyright
IBM
Corp.
_enter
the
year
or
years_.
All
rights
reserved.
92
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
If
you
are
viewing
this
information
softcopy,
the
photographs
and
color
illustrations
may
not
appear.
Trademarks
The
following
terms
are
trademarks
or
registered
trademarks
of
International
Business
Machines
Corporation
in
the
United
States,
other
countries,
or
both:
AIX
DB2
IBM
IBM
logo
OS/390
SecureWay
Tivoli
Tivoli
logo
Universal
Database
WebSphere
zSeries
z/OS
Java
and
all
Java-based
trademarks
and
logos
are
trademarks
or
registered
trademarks
of
Sun
Microsystems,
Inc.
in
the
United
States
and
other
countries.
Microsoft
and
Windows
are
trademarks
of
Microsoft
Corporation
in
the
United
States,
other
countries,
or
both.
Java
and
all
Java-based
trademarks
and
logos
are
trademarks
or
registered
trademarks
of
Sun
Microsystems,
Inc.
in
the
United
States
and
other
countries.
UNIX
is
a
registered
trademark
of
The
Open
Group
in
the
United
States
and
other
countries.
Other
company,
product,
or
service
names
may
be
trademarks
or
service
marks
of
others.
Appendix
D.
Notices
93
94
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Glossary
A
access
control.
In
computer
security,
the
process
of
ensuring
that
the
resources
of
a
computer
system
can
be
accessed
only
by
authorized
users
in
authorized
ways.
access
control
list
(ACL).
In
computer
security,
a
list
that
is
associated
with
an
object
that
identifies
all
the
subjects
that
can
access
the
object
and
their
access
rights.
For
example,
an
access
control
list
is
a
list
that
is
associated
with
a
file
that
identifies
the
users
who
can
access
the
file
and
identifies
the
users’
access
rights
to
that
file.
access
permission.
The
access
privilege
that
applies
to
the
entire
object.
action.
An
access
control
list
(ACL)
permission
attribute.
See
also
access
control
list.
ACL.
See
access
control
list.
administration
service.
An
authorization
API
runtime
plug-in
that
can
be
used
to
perform
administration
requests
on
a
Tivoli
Access
Manager
resource
manager
application.
The
administration
service
will
respond
to
remote
requests
from
the
pdadmin
command
to
perform
tasks,
such
as
listing
the
objects
under
a
particular
node
in
the
protected
object
tree.
Customers
may
develop
these
services
using
the
authorization
ADK.
attribute
list.
A
linked
list
that
contains
extended
information
that
is
used
to
make
authorization
decisions.
Attribute
lists
consist
of
a
set
of
name
=
value
pairs.
authentication.
(1)
In
computer
security,
verification
of
the
identity
of
a
user
or
the
user’s
eligibility
to
access
an
object.
(2)
In
computer
security,
verification
that
a
message
has
not
been
altered
or
corrupted.
(3)
In
computer
security,
a
process
that
is
used
to
verify
the
user
of
an
information
system
or
of
protected
resources.
See
also
multi-factor
authentication,
network-based
authentication,
and
step-up
authentication.
authorization.
(1)
In
computer
security,
the
right
granted
to
a
user
to
communicate
with
or
make
use
of
a
computer
system.
(2)
The
process
of
granting
a
user
either
complete
or
restricted
access
to
an
object,
resource,
or
function.
authorization
rule.
See
rule.
authorization
service
plug-in.
A
dynamically
loadable
library
(DLL
or
shared
library)
that
can
be
loaded
by
the
Tivoli
Access
Manager
authorization
API
runtime
client
at
initialization
time
in
order
to
perform
operations
that
extend
a
service
interface
within
the
Authorization
API.
The
service
interfaces
that
are
currently
available
include
Administration,
External
Authorization,
Credentials
modification,
Entitlements
and
PAC
manipulation
interfaces.
Customers
may
develop
these
services
using
the
authorization
ADK.
B
BA.
See
basic
authentication.
basic
authentication.
A
method
of
authentication
that
requires
the
user
to
enter
a
valid
user
name
and
password
before
access
to
a
secure
online
resource
is
granted.
bind.
To
relate
an
identifier
to
another
object
in
a
program;
for
example,
to
relate
an
identifier
to
a
value,
an
address
or
another
identifier,
or
to
associate
formal
parameters
and
actual
parameters.
blade.
A
component
that
provides
application-specific
services
and
components.
business
entitlement.
The
supplemental
attribute
of
a
user
credential
that
describes
the
fine-grained
conditions
that
can
be
used
in
the
authorization
of
requests
for
resources.
C
CA.
See
certificate
authority.
CDAS.
See
Cross
Domain
Authentication
Service.
CDMF.
See
Cross
Domain
Mapping
Framework.
certificate.
In
computer
security,
a
digital
document
that
binds
a
public
key
to
the
identity
of
the
certificate
owner,
thereby
enabling
the
certificate
owner
to
be
authenticated.
A
certificate
is
issued
by
a
certificate
authority.
certificate
authority
(CA).
An
organization
that
issues
certificates.
The
certificate
authority
authenticates
the
certificate
owner’s
identity
and
the
services
that
the
owner
is
authorized
to
use,
issues
new
certificates,
renews
existing
certificates,
and
revokes
certificates
belonging
to
users
who
are
no
longer
authorized
to
use
them.
CGI.
See
common
gateway
interface.
©
Copyright
IBM
Corp.
2001,
2003
95
cipher.
Encrypted
data
that
is
unreadable
until
it
has
been
converted
into
plain
data
(decrypted)
with
a
key.
common
gateway
interface
(CGI).
An
Internet
standard
for
defining
scripts
that
pass
information
from
a
Web
server
to
an
application
program,
through
an
HTTP
request,
and
vice
versa.
A
CGI
script
is
a
CGI
program
that
is
written
in
a
scripting
language,
such
as
Perl.
configuration.
(1)
The
manner
in
which
the
hardware
and
software
of
an
information
processing
system
are
organized
and
interconnected.
(2)
The
machines,
devices,
and
programs
that
make
up
a
system,
subsystem,
or
network.
connection.
(1)
In
data
communication,
an
association
established
between
functional
units
for
conveying
information.
(2)
In
TCP/IP,
the
path
between
two
protocol
applications
that
provides
reliable
data
stream
delivery
service.
In
the
Internet,
a
connection
extends
from
a
TCP
application
on
one
system
to
a
TCP
application
on
another
system.
(3)
In
system
communications,
a
line
over
which
data
can
be
passed
between
two
systems
or
between
a
system
and
a
device.
container
object.
A
structural
designation
that
organizes
the
object
space
into
distinct
functional
regions.
cookie.
Information
that
a
server
stores
on
a
client
machine
and
accesses
during
subsequent
sessions.
Cookies
allow
servers
to
remember
specific
information
about
clients.
credentials.
Detailed
information,
acquired
during
authentication,
that
describes
the
user,
any
group
associations,
and
other
security-related
identity
attributes.
Credentials
can
be
used
to
perform
a
multitude
of
services,
such
as
authorization,
auditing,
and
delegation.
credentials
modification
service.
An
authorization
API
runtime
plug-in
which
can
be
used
to
modify
a
Tivoli
Access
Manager
credential.
Credentials
modification
services
developed
externally
by
customers
are
limited
to
performing
operation
to
add
and
remove
from
the
credentials
attribute
list
and
only
to
those
attributes
that
are
considered
modifiable.
cross
domain
authentication
service
(CDAS).
A
WebSEAL
service
that
provides
a
shared
library
mechanism
that
allows
you
to
substitute
the
default
WebSEAL
authentication
mechanisms
with
a
custom
process
that
returns
a
Tivoli
Access
Manager
identity
to
WebSEAL.
See
also
WebSEAL.
cross
domain
mapping
framework
(CDMF).
A
programming
interface
that
allows
a
developer
to
customize
the
mapping
of
user
identities
and
the
handling
of
user
attributes
when
WebSEAL
e-Community
SSO
function
are
used.
D
daemon.
A
program
that
runs
unattended
to
perform
continuous
or
periodic
systemwide
functions,
such
as
network
control.
Some
daemons
are
triggered
automatically
to
perform
their
task;
others
operate
periodically.
directory
schema.
The
valid
attribute
types
and
object
classes
that
can
appear
in
a
directory.
The
attribute
types
and
object
classes
define
the
syntax
of
the
attribute
values,
which
attributes
must
be
present,
and
which
attributes
may
be
present
for
the
directory.
distinguished
name
(DN).
The
name
that
uniquely
identifies
an
entry
in
a
directory.
A
distinguished
name
is
made
up
of
attribute:value
pairs,
separated
by
commas.
digital
signature.
In
e-commerce,
data
that
is
appended
to,
or
is
a
cryptographic
transformation
of,
a
data
unit
and
that
enables
the
recipient
of
the
data
unit
to
verify
the
source
and
integrity
of
the
unit
and
to
recognize
potential
forgery.
DN.
See
distinguished
name.
domain.
(1)
A
logical
grouping
of
users,
systems,
and
resources
that
share
common
services
and
usually
function
with
a
common
purpose.
(2)
That
part
of
a
computer
network
in
which
the
data
processing
resources
are
under
common
control.
See
also
domain
name.
domain
name.
In
the
Internet
suite
of
protocols,
a
name
of
a
host
system.
A
domain
name
consists
of
a
sequence
of
subnames
that
are
separated
by
a
delimiter
character.
For
example,
if
the
fully
qualified
domain
name
(FQDN)
of
a
host
system
is
as400.rchland.vnet.ibm.com,
each
of
the
following
is
a
domain
name:
as400.rchland.vnet.ibm.com,
vnet.ibm.com,
ibm.com.
E
EAS.
See
External
Authorization
Service.
encryption.
In
computer
security,
the
process
of
transforming
data
into
an
unintelligible
form
in
such
a
way
that
the
original
data
either
cannot
be
obtained
or
can
be
obtained
only
by
using
a
decryption
process.
entitlement.
A
data
structure
that
contains
externalized
security
policy
information.
Entitlements
contain
policy
data
or
capabilities
that
are
formatted
in
a
way
that
is
understandable
to
a
specific
application.
entitlement
service.
An
authorization
API
runtime
plug-in
which
can
be
used
to
return
entitlements
from
an
external
source
for
a
principal
or
set
of
conditions.
Entitlements
are
normally
application
specific
data
that
will
be
consumed
by
the
resource
manager
application
96
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
in
some
way
or
added
to
the
principal’s
credentials
for
use
further
on
in
the
authorization
process.
Customers
may
develop
these
services
using
the
authorization
ADK.
external
authorization
service.
An
authorization
API
runtime
plug-in
that
can
be
used
to
make
application
or
environment
specific
authorization
decisions
as
part
of
the
Tivoli
Access
Manager
authorization
decision
chain.
Customers
may
develop
these
services
using
the
authorization
ADK.
F
file
transfer
protocol
(FTP).
In
the
Internet
suite
of
protocols,
an
application
layer
protocol
that
uses
Transmission
Control
Protocol
(TCP)
and
Telnet
services
to
transfer
bulk-data
files
between
machines
or
hosts.
G
global
signon
(GSO).
A
flexible
single
sign-on
solution
that
enables
the
user
to
provide
alternative
user
names
and
passwords
to
the
back-end
Web
application
server.
Global
signon
grants
users
access
to
the
computing
resources
they
are
authorized
to
use
—
through
a
single
login.
Designed
for
large
enterprises
consisting
of
multiple
systems
and
applications
within
heterogeneous,
distributed
computing
environments,
GSO
eliminates
the
need
for
users
to
manage
multiple
user
names
and
passwords.
See
also
single
signon.
GSO.
See
global
signon.
H
host.
A
computer
that
is
connected
to
a
network
(such
as
the
Internet
or
an
SNA
network)
and
provides
an
access
point
to
that
network.
Also,
depending
on
the
environment,
the
host
may
provide
centralized
control
of
the
network.
The
host
can
be
a
client,
a
server,
or
both
a
client
and
a
server
simultaneously.
HTTP.
See
Hypertext
Transfer
Protocol.
hypertext
transfer
protocol
(HTTP).
In
the
Internet
suite
of
protocols,
the
protocol
that
is
used
to
transfer
and
display
hypertext
documents.
I
Internet
protocol
(IP).
In
the
Internet
suite
of
protocols,
a
connectionless
protocol
that
routes
data
through
a
network
or
interconnected
networks
and
acts
as
an
intermediary
between
the
higher
protocol
layers
and
the
physical
network.
Internet
suite
of
protocols.
A
set
of
protocols
developed
for
use
on
the
Internet
and
published
as
Requests
for
Comments
(RFCs)
through
the
Internet
Engineering
Task
Force
(IETF).
interprocess
communication
(IPC).
(1)
The
process
by
which
programs
communicate
data
to
each
other
and
synchronize
their
activities.
Semaphores,
signals,
and
internal
message
queues
are
common
methods
of
interprocess
communication.
(2)
A
mechanism
of
an
operating
system
that
allows
processes
to
communicate
with
each
other
within
the
same
computer
or
over
a
network.
IP.
See
Internet
Protocol.
IPC.
See
Interprocess
Communication.
J
junction.
An
HTTP
or
HTTPS
connection
between
a
front-end
WebSEAL
server
and
a
back-end
Web
application
server.
WebSEAL
uses
a
junction
to
provide
protective
services
on
behalf
of
the
back-end
server.
K
key.
In
computer
security,
a
sequence
of
symbols
that
is
used
with
a
cryptographic
algorithm
for
encrypting
or
decrypting
data.
See
private
key
and
public
key.
key
database
file.
See
key
ring.
key
file.
See
key
ring.
key
pair.
In
computer
security,
a
public
key
and
a
private
key.
When
the
key
pair
is
used
for
encryption,
the
sender
uses
the
public
key
to
encrypt
the
message,
and
the
recipient
uses
the
private
key
to
decrypt
the
message.
When
the
key
pair
is
used
for
signing,
the
signer
uses
the
private
key
to
encrypt
a
representation
of
the
message,
and
the
recipient
uses
the
public
key
to
decrypt
the
representation
of
the
message
for
signature
verification.
key
ring.
In
computer
security,
a
file
that
contains
public
keys,
private
keys,
trusted
roots,
and
certificates.
L
LDAP.
See
Lightweight
Directory
Access
Protocol.
lightweight
directory
access
protocol
(LDAP).
An
open
protocol
that
(a)
uses
TCP/IP
to
provide
access
to
directories
that
support
an
X.500
model
and
(b)
does
not
incur
the
resource
requirements
of
the
more
complex
X.500
Directory
Access
Protocol
(DAP).
Applications
that
use
LDAP
(known
as
directory-enabled
applications)
can
use
the
directory
as
a
common
data
store
and
for
retrieving
information
about
people
or
services,
such
as
addresses,
public
keys,
or
service-specific
configuration
parameters.
LDAP
was
originally
specified
in
RFC
Glossary
97
1777.
LDAP
version
3
is
specified
in
RFC
2251,
and
the
IETF
continues
work
on
additional
standard
functions.
Some
of
the
IETF-defined
standard
schemas
for
LDAP
are
found
in
RFC
2256.
lightweight
third
party
authentication
(LTPA).
An
authentication
framework
that
allows
single
sign-on
across
a
set
of
Web
servers
that
fall
within
an
Internet
domain.
LTPA.
See
lightweight
third
party
authentication.
M
management
domain.
The
default
domain
in
which
Tivoli
Access
Manager
enforces
security
policies
for
authentication,
authorization,
and
access
control.
This
domain
is
created
when
the
policy
server
is
configured.
See
also
domain.
management
server.
Obsolete.
See
policy
server.
metadata.
Data
that
describes
the
characteristics
of
stored
data.
migration.
The
installation
of
a
new
version
or
release
of
a
program
to
replace
an
earlier
version
or
release.
multi-factor
authentication.
A
protected
object
policy
(POP)
that
forces
a
user
to
authenticate
using
two
or
more
levels
of
authentication.
For
example,
the
access
control
on
a
protected
resource
can
require
that
the
users
authenticate
with
both
user
name/password
and
user
name/token
passcode.
See
also
protected
object
policy.
multiplexing
proxy
agent
(MPA).
A
gateway
that
accommodates
multiple
client
access.
These
gateways
are
sometimes
known
as
Wireless
Access
Protocol
(WAP)
gateways
when
clients
access
a
secure
domain
using
a
WAP.
Gateways
establish
a
single
authenticated
channel
to
the
originating
server
and
tunnel
all
client
requests
and
responses
through
this
channel.
N
network-based
authentication.
A
protected
object
policy
(POP)
that
controls
access
to
objects
based
on
the
internet
protocol
(IP)
address
of
the
user.
See
also
protected
object
policy.
P
PAC.
See
privilege
attribute
certificate.
permission.
The
ability
to
access
a
protected
object,
such
as
a
file
or
directory.
The
number
and
meaning
of
permissions
for
an
object
are
defined
by
the
access
control
list
(ACL).
See
also
access
control
list.
policy.
A
set
of
rules
that
are
applied
to
managed
resources.
policy
server.
The
Tivoli
Access
Manager
server
that
maintains
the
location
information
about
other
servers
in
the
secure
domain.
polling.
The
process
by
which
databases
are
interrogated
at
regular
intervals
to
determine
if
data
needs
to
be
transmitted.
POP.
See
protected
object
policy.
portal.
An
integrated
Web
site
that
dynamically
produces
a
customized
list
of
Web
resources,
such
as
links,
content,
or
services,
available
to
a
specific
user,
based
on
the
access
permissions
for
the
particular
user.
privilege
attribute
certificate.
A
digital
document
that
contains
a
principal’s
authentication
and
authorization
attributes
and
a
principal’s
capabilities.
privilege
attribute
certificate
service.
An
authorization
API
runtime
client
plug-in
which
translates
a
PAC
of
a
predetermined
format
in
to
a
Tivoli
Access
Manager
credential,
and
vice-versa.
These
services
could
also
be
used
to
package
or
marshall
a
Tivoli
Access
Manager
credential
for
transmission
to
other
members
of
the
secure
domain.
Customers
may
develop
these
services
using
the
authorization
ADK.
See
also
privilege
attribute
certificate.
protected
object.
The
logical
representation
of
an
actual
system
resource
that
is
used
for
applying
ACLs
and
POPs
and
for
authorizing
user
access.
See
also
protected
object
policy
and
protected
object
space.
protected
object
policy
(POP).
A
type
of
security
policy
that
imposes
additional
conditions
on
the
operation
permitted
by
the
ACL
policy
to
access
a
protected
object.
It
is
the
responsibility
of
the
resource
manager
to
enforce
the
POP
conditions.
See
also
access
control
list,
protected
object,
and
protected
object
space.
protected
object
space.
The
virtual
object
representation
of
actual
system
resources
that
is
used
for
applying
ACLs
and
POPs
and
for
authorizing
user
access.
See
also
protected
object
and
protected
object
policy.
private
key.
In
computer
security,
a
key
that
is
known
only
to
its
owner.
Contrast
with
public
key.
public
key.
In
computer
security,
a
key
that
is
made
available
to
everyone.
Contrast
with
private
key.
Q
quality
of
protection.
The
level
of
data
security,
determined
by
a
combination
of
authentication,
integrity,
and
privacy
conditions.
98
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
R
registry.
The
datastore
that
contains
access
and
configuration
information
for
users,
systems,
and
software.
replica.
A
server
that
contains
a
copy
of
the
directory
or
directories
of
another
server.
Replicas
back
up
servers
in
order
to
enhance
performance
or
response
times
and
to
ensure
data
integrity.
resource
object.
The
representation
of
an
actual
network
resource,
such
as
a
service,
file,
and
program.
response
file.
A
file
that
contains
a
set
of
predefined
answers
to
questions
asked
by
a
program
and
that
is
used
instead
of
entering
those
values
one
at
a
time.
role
activation.
The
process
of
applying
the
access
permissions
to
a
role.
role
assignment.
The
process
of
assigning
a
role
to
a
user,
such
that
the
user
has
the
appropriate
access
permissions
for
the
object
defined
for
that
role.
routing
file.
An
ASCII
file
that
contains
commands
that
control
the
configuration
of
messages.
RSA
encryption.
A
system
for
public-key
cryptography
used
for
encryption
and
authentication.
It
was
invented
in
1977
by
Ron
Rivest,
Adi
Shamir,
and
Leonard
Adleman.
The
system’s
security
depends
on
the
difficulty
of
factoring
the
product
of
two
large
prime
numbers.
rule.
One
or
more
logical
statements
that
enable
the
event
server
to
recognize
relationships
among
events
(event
correlation)
and
to
execute
automated
responses
accordingly.
run
time.
The
time
period
during
which
a
computer
program
is
executing.
A
runtime
environment
is
an
execution
environment.
S
scalability.
The
ability
of
a
network
system
to
respond
to
increasing
numbers
of
users
who
access
resources.
schema.
The
set
of
statements,
expressed
in
a
data
definition
language,
that
completely
describe
the
structure
of
a
database.
In
a
relational
database,
the
schema
defines
the
tables,
the
fields
in
each
table,
and
the
relationships
between
fields
and
tables.
secure
sockets
layer
(SSL).
A
security
protocol
that
provides
communication
privacy.
SSL
enables
client/server
applications
to
communicate
in
a
way
that
is
designed
to
prevent
eavesdropping,
tampering,
and
message
forgery.
SSL
was
developed
by
Netscape
Communications
Corp.
and
RSA
Data
Security,
Inc.
security
management.
The
management
discipline
that
addresses
an
organization’s
ability
to
control
access
to
applications
and
data
that
are
critical
to
its
success.
self-registration.
The
process
by
which
a
user
can
enter
required
data
and
become
a
registered
Tivoli
Access
Manager
user,
without
the
involvement
of
an
administrator.
service.
Work
performed
by
a
server.
A
service
can
be
a
simple
request
for
data
to
be
sent
or
stored
(as
with
file
servers,
HTTP
servers,
servers,
and
finger
servers),
or
it
can
be
more
complex
work
such
as
that
of
servers
or
process
servers.
silent
installation.
An
installation
that
does
not
send
messages
to
the
console
but
instead
stores
messages
and
errors
in
log
files.
Also,
a
silent
installation
can
use
response
files
for
data
input.
See
also
response
file.
single
signon
(SSO).
The
ability
of
a
user
to
logon
once
and
access
multiple
applications
without
having
to
logon
to
each
application
separately.
See
also
global
signon.
SSL.
See
Secure
Sockets
Layer.
SSO.
See
Single
Signon.
step-up
authentication.
A
protected
object
policy
(POP)
that
relies
on
a
preconfigured
hierarchy
of
authentication
levels
and
enforces
a
specific
level
of
authentication
according
to
the
policy
set
on
a
resource.
The
step-up
authentication
POP
does
not
force
the
user
to
authenticate
using
multiple
levels
of
authentication
to
access
any
given
resource
but
requires
the
user
to
authenticate
at
a
level
at
least
as
high
as
that
required
by
the
policy
protecting
a
resource.
suffix.
A
distinguished
name
that
identifies
the
top
entry
in
a
locally
held
directory
hierarchy.
Because
of
the
relative
naming
scheme
used
in
Lightweight
Directory
Access
Protocol
(LDAP),
this
suffix
applies
to
every
other
entry
within
that
directory
hierarchy.
A
directory
server
can
have
multiple
suffixes,
each
identifying
a
locally
held
directory
hierarchy.
T
token.
(1)
In
a
local
area
network,
the
symbol
of
authority
passed
successively
from
one
data
station
to
another
to
indicate
the
station
temporarily
in
control
of
the
transmission
medium.
Each
data
station
has
an
opportunity
to
acquire
and
use
the
token
to
control
the
medium.
A
token
is
a
particular
message
or
bit
pattern
that
signifies
permission
to
transmit.
(2)
In
local
area
networks
(LANs),
a
sequence
of
bits
passed
from
one
device
to
another
along
the
transmission
medium.
When
the
token
has
data
appended
to
it,
it
becomes
a
frame.
Glossary
99
trusted
root.
In
the
Secure
Sockets
Layer
(SSL),
the
public
key
and
associated
distinguished
name
of
a
certificate
authority
(CA).
U
uniform
resource
identifier
(URI).
The
character
string
used
to
identify
content
on
the
Internet,
including
the
name
of
the
resource
(a
directory
and
file
name),
the
location
of
the
resource
(the
computer
where
the
directory
and
file
name
exist),
and
how
the
resource
can
be
accessed
(the
protocol,
such
as
HTTP).
An
example
of
a
URI
is
a
uniform
resource
locator,
or
URL.
uniform
resource
locator
(URL).
A
sequence
of
characters
that
represent
information
resources
on
a
computer
or
in
a
network
such
as
the
Internet.
This
sequence
of
characters
includes
(a)
the
abbreviated
name
of
the
protocol
used
to
access
the
information
resource
and
(b)
the
information
used
by
the
protocol
to
locate
the
information
resource.
For
example,
in
the
context
of
the
Internet,
these
are
abbreviated
names
of
some
protocols
used
to
access
various
information
resources:
http,
ftp,
gopher,
telnet,
and
news;
and
this
is
the
URL
for
the
IBM
home
page:
http://www.ibm.com.
URI.
See
uniform
resource
identifier.
URL.
See
uniform
resource
locator.
user.
Any
person,
organization,
process,
device,
program,
protocol,
or
system
that
uses
a
service
provided
by
others.
user
registry.
See
registry.
V
virtual
hosting.
The
capability
of
a
Web
server
that
allows
it
to
appear
as
more
than
one
host
to
the
Internet.
W
Web
Portal
Manager
(WPM).
A
Web-based
graphical
application
used
to
manage
Tivoli
Access
Manager
Base
and
WebSEAL
security
policy
in
a
secure
domain.
An
alternative
to
the
pdadmin
command
line
interface,
this
GUI
enables
remote
administrator
access
and
enables
administrators
to
create
delegated
user
domains
and
assign
delegate
administrators
to
these
domains.
WebSEAL.
A
Tivoli
Access
Manager
blade.
WebSEAL
is
a
high
performance,
multi-threaded
Web
server
that
applies
a
security
policy
to
a
protected
object
space.
WebSEAL
can
provide
single
sign-on
solutions
and
incorporate
back-end
Web
application
server
resources
into
its
security
policy.
WPM.
See
Web
Portal
Manager.
100
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
Index
Aadministering
plug-in
for
Edge
Server
11
authenticationCDSSO
49
authorizing
users
24
authtoken-lifetime
53
BBase
configuration
file
14
Basic
Authentication
18
Ccaching
proxy
2
CDASAPI
core
function
reference
44
authentication
models
35
dispatched
authentication
model
36
single
authentication
model
35
building
38
CDAS
example
41
CDAS
scenario
41
compiling
40
configuring
41
configuring
plug-in
for
Edge
Server
to
use
a
CDAS
41
core
and
utility
functions
44
demonstration
library
42
loading
43
programming
38
returning
the
client
identity
40
CDMF
library
49
CDSSOdefinitions
83
CDSSO
authentication
49
an
example
54
disabled
51
enabled
51
cdsso_key_gen
52,
59
cdsso-peers
stanza
52
certificate
authentication
20
configuratione-community
single
signon
61
file
reference
69
object
space
definition
71
summarized
28
understanding
23
configuration
files
13
base
configuration
file
(ibmwesas.conf)
14
object
space
definition
configuration
file
(osdef.conf)
14
user
mapping
configuration
file
(usermap.conf)
16
configuringlogin
method
17
configuring
plug-in
for
Edge
Server
9
cross-domain
authentication
serviceSee
CDAS
cross-domain
signonCDSSO
49
Ddemonstration
library
42
deploying
the
plug-in
for
Edge
Server
31
disk
requirements
7
Ee-community
single
signonan
example
62
configuration
61
cookie
58
disabling
60
enabling
60
features
and
requirements
56
overview
55
process
flow
56
examplesCDAS
scenario
41
configuring
the
Web
site
32
content
distribution
31
designing
the
web
site
31
log
files
16
single
signon
31
Fform
authentication
18
forward
proxy
access
control
4
Iibmwesas.conf
14,
69
implementing
the
plug-in
for
Edge
Server
31
installing
plug-in
for
Edge
Server
7
configuring
plug-in
for
Edge
ServerSee
configuring
plug-in
for
Edge
Server
on
AIX
8
on
Linux
8
on
Solaris
9
on
Windows
9
upgrading
plug-in
for
Edge
ServerSee
upgrading
plug-in
for
Edge
Server
Llog
file
disk
requirements
7
log
files
16
login
method
17
Basic
Authentication
18
login
method
(continued)client
certificates
20
form
login
18
Mmemory
requirements
7
Nnetwork
dispatcher
2
Oobject
spacecreating
11
creating
for
caching
proxy
12
creating
for
other
Web
servers
12
object
space
configuration
model
26
object
space
definition
configuration
file
14
osdef.conf
14
Ppkmscdsso
51
prerequisitessoftware
8
proxy
access
control
3
forward
4
reverse
3
Rrelated
publications
x
removing
the
plug-in
for
Edge
Server
65
requirementssystem
1
reverse
proxy
access
control
3
Ssecurity
enforcementcaching
proxy
2
network
dispatcher
2
security
model
1
server
configuration
model
23
server
definitions
71
single
signonCDSSO
49
e-community
55
single
signon
configuration
model
28
single
signon
definitions
81
starting
and
stopping
plug-in
for
Edge
Server
13
supported
platforms
7
system
requirements
1
©
Copyright
IBM
Corp.
2001,
2003
101
Ttag-value
pair
configuration
model
21
Tivoli
Access
Manager
security
model
1
token
label
name
52
token
protection,
CDSSO
54
Uuninstalling
the
plug-in
for
Edge
ServerSee
removing
the
plug-in
for
Edge
Server
upgrading
plug-in
for
Edge
Server
10
user
accounts,
managing
11
user
authentication
data
39
user
mapping
configuration
file
16
usermap.conf
16
utilitieswesosm
86
wslstartwte
88
wslstopwte
89
Vvouch-for
request
and
reply
58
token
59
Wwesosm
command
syntax
85
wesosm
utility
86
wslstartwte
13
wslstartwte
utility
88
wslstopwte
13
wslstopwte
utility
89
Xxauthn_authenticate()
45
xauthn_change_password()
46
xauthn_initialize()
47
xauthn_shutdown()
48
102
IBM
Tivoli
Access
Manager
for
e-business:
Plug-in
for
IBM
WebSphere
Edge
Server
Integration
Guide
����
Printed
in
USA
SC32-1367-00