Embed Size (px)
Citation preview
IBM
Tivoli
Access
Manager
for
e-business
Web
Security
Developer
Reference
Version
5.1
SC32-1358-00
���
IBM
Tivoli
Access
Manager
for
e-business
Web
Security
Developer
Reference
Version
5.1
SC32-1358-00
���
Note
Before
using
this
information
and
the
product
it
supports,
read
the
information
in
Appendix
D,
“Notices,”
on
page
81.
First
Edition
(November
2003)
This
edition
replaces
GC32-0685-01
©
Copyright
International
Business
Machines
Corporation
1999,
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
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. viii
Web
security
information
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. ix
Developer
references
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. ix
Technical
supplements
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. x
Related
publications
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. x
IBM
Global
Security
Kit
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. x
IBM
Tivoli
Directory
Server
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xi
IBM
DB2
Universal
Database
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xi
IBM
WebSphere
Application
Server
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xi
IBM
Tivoli
Access
Manager
for
Business
Integration
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xi
IBM
Tivoli
Access
Manager
for
WebSphere
Business
Integration
Brokers
.
.
.
.
.
.
.
.
.
.
.
.
. xii
IBM
Tivoli
Access
Manager
for
Operating
Systems
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xii
IBM
Tivoli
Identity
Manager
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiii
Accessing
publications
online
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiii
Accessibility
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiii
Contacting
software
support
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiii
Conventions
used
in
this
book
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiv
Typeface
conventions
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiv
Operating
system
differences
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiv
Chapter
1.
Web
security
authentication
framework
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 1
Authentication
modules
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 2
What
is
a
CDAS?
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 2
Authentication
framework
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 3
Web
security
resource
manager
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 3
Tivoli
Access
Manager
Base
runtime
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 3
Tivoli
Access
Manager
authorization
API
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 4
External
authentication
(xauthn)
interface
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 4
External
authentication
interface
functions
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 4
How
authentication
methods
are
implemented
using
the
authentication
framework
.
.
.
.
.
.
.
.
.
.
. 5
Authentication
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 5
Changing
passwords
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 6
Adding
extended
attributes
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 6
Post
password
change
processing
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 7
Password
strength
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 7
How
to
use
this
developer
reference
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 9
Chapter
2.
Application
development
kit
overview
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 11
External
authentication
API
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 12
Cross-domain
mapping
framework
API
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 13
Password
strength
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 14
EPAC
demonstration
application
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 15
Chapter
3.
Customizing
authentication
modules
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 17
Using
the
external
authentication
API
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 18
Software
requirements
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 18
Build
instructions
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 18
Example
library
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 19
API
functions
and
data
types
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 20
Initializing
and
shutting
down
the
API
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 20
©
Copyright
IBM
Corp.
1999,
2003
iii
Extended
attributes
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 21
User
identity
information
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 21
Authentication
data
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 22
User
authentication
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 24
Obtain
user
authentication
information
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 24
Identifiers
common
to
all
authentication
methods
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 24
Username/password
authentication
identifiers
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 25
Certificate
authentication
identifiers
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 25
Token
card
authentication
identifiers
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 26
HTTP
authentication
identifiers
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 26
Switch
user
authentication
identifiers
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 26
Authenticate
the
user
identity
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 28
Convert
the
credential
to
string
format
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 28
Return
user
identity
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 28
Change
user
password
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 29
Add
extended
attributes
to
the
credential
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 30
Password
strength
checking
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 32
Post
password
change
processing
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 33
UTF-8
compatibility
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 34
UTF-8
compatibility
for
custom
authentication
libraries
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 34
User
credential
data
format
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 34
Entitlements
service
data
format
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 34
Conversion
library
for
authentication
data
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 35
Configuring
the
conversion
library
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 35
Authentication
module
configuration
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 37
Chapter
4.
Cross-domain
single
sign-on
authentication
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 39
Overview
of
cross-domain
single
sign-on
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 40
Default
token
creation
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 41
Default
token
consumption
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 41
Mapping
user
identities
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 42
Identity
mapping
across
domains
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 42
Identity
mapping
in
an
e-community
environment
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 42
Implementing
custom
token
create
and
consume
libraries
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 44
Example
libraries
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 44
Creating
and
building
a
custom
token
create/consume
library
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 45
Customizing
the
token
create
library
interface
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 45
Customizing
the
token
consume
library
interface
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 47
Implementing
cross-domain
mapping
framework
libraries
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 48
Software
requirements
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 48
Build
instructions
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 48
Customizing
the
example
source
file
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 49
Cross-domain
mapping
framework
functions
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 49
Providing
user
attributes:
cdmf_get_usr_attributes()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 50
Providing
identity
mapping:
cdmf_map_usr()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 50
Specifying
extended
attributes
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 51
Configuration
instructions
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 52
Sending
single
sign-on
requests
to
a
non-WebSEAL
server
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 52
Accepting
single
sign-on
requests
from
a
non-WebSEAL
server
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 52
Appendix
A.
External
authentication
C
API
reference
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 55
xnvlist_get()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 56
xattr_get()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 57
xattr_set()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 58
xauthn_authenticate()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 59
xauthn_change_password()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 60
xauthn_initialize()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 61
xauthn_shutdown()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 62
xauthn_util_entry_to_creds()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 63
iv
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Appendix
B.
Cross-domain
mapping
framework
C
API
reference
.
.
.
.
.
.
.
.
.
.
. 65
cdmf_add_attr_to_list()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 66
cdmf_add_value_to_attr()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 67
cdmf_create_usr_attr()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 68
cdmf_create_usr_attr_list()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 69
cdmf_get_usr_attributes()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 70
cdmf_map_usr()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 71
CDSSO_FREE()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 73
CDSSO_MALLOC()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 74
CDSSO_REALLOC()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 75
CDSSO_STRDUP()
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 76
Appendix
C.
User
registry
differences
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 77
Appendix
D.
Notices
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 81
Trademarks
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 83
Index
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 85
Contents
v
vi
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Preface
Welcome
to
the
IBM®Tivoli®Access
Manager
for
e-business
Web
Security
Developer
Reference.
This
document
provides
programming
information
and
references
for
developing
authentication
modules
by
using
the
external
authentication
API.
It
also
includes
instructions
for
developing
authentication
modules
that
provide
cross-domain
single
sign-on
authentication.
The
use
of
the
cross-domain
mapping
framework
to
enhance
cross-domain
single
sign-on
is
also
described.
The
document
contains
the
API
references
for
the
external
authentication
C
API
and
the
cross-domain
mapping
framework
API.
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.
Who
should
read
this
book
This
guide
is
for
system
administrators
responsible
for
the
installation,
deployment,
and
administration
of
Tivoli
Access
Manager.
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
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
document
contains
the
following
chapters:
v
Chapter
1,
″Web
security
authentication
framework″
An
overview
of
the
Web
security
authentication
framework.
v
Chapter
2,
″Application
development
kit
overview″
A
description
of
the
application
development
kit
contents,
and
the
data
types
and
functions
for
each
API
©
Copyright
IBM
Corp.
1999,
2003
vii
v
Chapter
3,
″Customizing
authentication
modules″
Instructions
for
writing
a
custom
authentication
module.
v
Chapter
4,
″Cross-domain
single
sign-on″
Instructions
for
implementing
a
cross-domain
single
sign-on
solution.
v
Appendix
A
–
External
authentication
C
API
reference
Reference
pages
for
the
external
authentication
C
API.
v
Appendix
B
—
Cross-domain
mapping
framework
C
API
reference
Reference
pages
for
the
cross-domain
mapping
framework
C
API.
v
Appendix
C
—
User
registry
differences
User
registry
differences
that
can
affect
authentication.
v
Appendix
D
—
Notices
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”
v
“Web
security
information”
on
page
ix
v
“Developer
references”
on
page
ix
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)
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)
viii
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
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)
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)
Preface
ix
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
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.
x
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
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
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
Preface
xi
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)
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:
xii
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
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.
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/
Preface
xiii
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:
Web
Security
Developer
Reference
Chapter
1.
Web
security
authentication
framework
Tivoli
Access
Manager
provides
a
Web
Security
application
development
kit
that
enables
you
to
write
programs
that
extend
the
functionality
of
the
authentication
modules
used
during
the
user
authentication
process.
The
ADK
provides
two
programmatic
interfaces
that
enable
you
to
either
customize
the
built-in
authentication
modules
or
write
replacement
modules.
The
ADK
also
provides
an
example
program
that
demonstrates
how
to
use
the
authorization
API
to
extract
user
credential
attributes.
This
is
included
because
it
is
helpful
in
testing
the
results
of
authentication
operations.
The
Tivoli
Access
Manager
Web
Security
application
development
kit
can
be
used
with
either
Tivoli
Access
Manager
WebSEAL
or
Tivoli
Access
Manager
Plug-in
for
Web
Servers.
Both
of
these
components
supply
the
server
processing
that
handles
authentication
requests.
You
can
use
the
interfaces
provided
by
the
Tivoli
Access
Manager
Web
Security
application
development
kit
to
write
customized
authentication
modules
for
use
by
either
of
the
Tivoli
Access
Manager
Web
security
components.
This
developer
reference
uses
the
term
Web
security
resource
manager.
This
term
includes
the
WebSEAL
component
and
the
Tivoli
Access
Manager
Plug-in
for
Web
servers
component.
The
term
resource
manager
is
used
by
Tivoli
Access
Manager
to
describe
an
application
or
process
that
handles
requests
from
users
and
then
engages
with
the
Tivoli
Access
Manager
authorization
service
to
determine
if
the
user
should
be
allowed
to
perform
the
requested
action
on
the
requested
protected
resource.
Note
that
the
Plug-in
for
Web
servers
runs
in
the
same
process
as
an
external
Web
server,
such
as
Microsoft
IIS.
Thus,
in
this
developer
reference,
the
term
Web
security
resource
manager
can
refer
not
only
to
the
WebSEAL
server,
but
also
can
refer
to
a
server
process
that
includes
the
external
Web
server
plus
the
security
functions
provided
by
the
Tivoli
Access
Manager
Plug-in
for
Web
servers.
For
more
information
on
the
Tivoli
Access
Manager
Web
security
components,
see:
v
IBM
Tivoli
Access
Manager
for
e-business
WebSEAL
Administration
Guide
v
IBM
Tivoli
Access
Manager
for
e-business
Plug-in
for
Web
Servers
Integration
Guide
This
chapter
contains
the
following
topics:
v
“Authentication
modules”
on
page
2
v
“Authentication
framework”
on
page
3
v
“How
authentication
methods
are
implemented
using
the
authentication
framework”
on
page
5
v
“How
to
use
this
developer
reference”
on
page
9
©
Copyright
IBM
Corp.
1999,
2003
1
Authentication
modules
The
Web
security
resource
managers
are
designed
are
designed
to
process
a
set
of
authentication
methods.
These
authentication
methods
each
support
one
or
more
authentication
operations.
The
libraries
that
process
the
authentication
methods
are
called
authentication
modules.
v
Authentication
operations
Tivoli
Access
Manager
supports
a
number
of
authentication
operations.
An
authentication
operation
is
any
operation
that
affects
the
process
of
authentication.
Examples
include,
but
are
not
limited
to:
–
Performing
username/password
authentication
by
performing
a
lookup
in
LDAP
–
Changing
a
user
password
–
Verifying
that
a
new
password
meets
certain
criteria
–
Add
attributes
to
an
authenticated
identityv
Authentication
methods
An
authentication
method
refers
a
logical
set
of
authentication
operations.
Typically,
but
not
always,
authentication
methods
have
a
one
to
one
relationship
with
a
particular
type
of
data
used
to
prove
a
user’s
identity.
Examples
of
authentication
methods
include,
but
are
not
limited
to:
–
Username/password
–
Token
–
Certificate
A
given
authentication
method
may
have
more
than
one
authentication
operation
associated
with
it.
For
example,
the
token
authentication
method
includes
the
operations
of
authenticating,
creating
a
new
PIN
number,
and
prompting
a
user
to
enter
a
new
PIN.
Some
methods
may
not
perform
an
actual
authentication
at
all.
An
example
is
the
extended
attributes
(cred-ext-attrs)
method,
whose
sole
function
is
to
add
new
attributes
to
an
authenticated
identity
before
a
credential
is
constructed.
v
Authentication
modules
The
functions
that
implement
the
authentication
operations
associated
with
each
authentication
method
are
contained
in
libraries
called
authentication
modules.
This
means
that
there
is
a
one-to-one
mapping
between
an
authentication
method
and
an
authentication
module.
For
example,
if
a
user
provides
authentication
data
using
the
password
authentication
method,
the
same
module
is
used
to
both
authenticate
that
user
as
well
as
to
change
their
password
(should
they
choose
to
do
so).
The
authentication
module
libraries
are
dynamic
and
are
written
as
plug-ins.
They
can
be
replaced
with
new
versions,
and
when
the
Web
security
resource
manager
is
restarted,
it
will
use
the
new
authentication
module
to
handle
the
operations
associated
with
a
particular
authentication
method.
Both
standard
built-in
and
custom
authentication
modules
load
directly
into
the
Web
security
resource
manager
memory
and
run
as
part
of
the
server
process.
What
is
a
CDAS?
In
previous
releases,
the
authentication
modules
described
in
the
previous
section
were
referred
to
as
cross-domain
authentication
services
or
CDAS
libraries.
This
term
is
no
longer
used
because
the
scope
of
the
term
CDAS
is
no
longer
wide
enough
to
cover
all
the
functions
performed
by
Web
security
resource
manager
authentication
modules.
This
change
reflects
only
a
change
in
terminology.
2
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Authentication
framework
Tivoli
Access
Manager
uses
a
flexible
framework
that
allows
the
functions
that
handle
authentication
operations
to
be
easily
modified
or
replaced.
This
diagram
shows
the
main
components
used
in
the
processing
of
authentication
operations.
The
following
sections
describe
what
each
of
the
components
does.
Web
security
resource
manager
This
can
be
either
the
WebSEAL
component
or
the
Plug-in
for
Web
Servers
component.
v
Extracts
authentication
data
from
user
requests
and
provides
it
to
the
Base
runtime.
v
Receives
the
results
of
authentication
operations
from
the
Base
runtime.
The
results
can
be
statuses
or,
in
the
case
of
actual
authentication,
user
credentials
that
represent
authenticated
accounts.
Tivoli
Access
Manager
Base
runtime
This
is
the
set
of
libraries
provided
in
the
Tivoli
Access
Manager
runtime
installation
package.
These
Tivoli
Access
Manager
libraries
are
separate
from
the
authentication
modules.
They
provide
core
Tivoli
Access
Manager
security
management
functions
for
use
by
a
variety
of
resource
managers,
including
some
that
are
unrelated
to
Web
security.
The
Web
security
resource
managers
require
these
libraries
as
a
prerequisite.
The
libraries
are
not
customizable.
The
Tivoli
Access
ManagerBase
runtime
libraries
perform
the
following
tasks:
v
Pass
authentication
data
to
the
external
authentication
(xauthn)
interface.
v
Receive
statuses
or,
when
authentication
occurs,
identity
structures
back
from
the
external
authentication
interface.
Note:
An
identity
structure
is
a
collection
of
data
that
represents
an
authenticated
user.
v
Pass
authentication
data
or
identity
structures
back
to
the
external
authentication
interface.
(This
step
is
not
done
in
all
cases)
v
Determine
if
an
identity
was
received
from
the
external
authentication
interface
(after
interactions
with
the
external
authentication
interface
are
complete)
.
When
this
is
true,
the
runtime
passes
the
identity
to
the
Tivoli
Access
Manager
authorization
API
to
build
a
credential.
v
Receive
statuses
and/or
credentials
back
from
the
authorization
API
and
pass
these
to
the
Web
security
resource
manager.
Figure
1.
Tivoli
Access
Manager
Web
security
authentication
framework
Chapter
1.
Web
security
authentication
framework
3
Tivoli
Access
Manager
authorization
API
This
authorization
API
is
part
of
the
Tivoli
Access
Manager
Base
functionality.
It
performs
authorization
tasks,
including
the
following:
v
Receives
an
identity
structure
from
the
Base
runtime.
v
Extracts
the
user
name
contained
in
the
identity
structure.
v
Attempts
to
find
the
user
name
in
the
Tivoli
Access
Manager
user
registry.
v
When
successful,
constructs
a
user
credential.
v
Returns
the
credential
to
the
Base
runtime.
External
authentication
(xauthn)
interface
This
interface
performs
the
following
tasks:
v
Receives
authentication
data
from
the
Base
runtime.
v
Organizes
the
data
into
a
standard
format.
v
Passes
the
data
to
the
authentication
modules.
v
Receives
statuses
and/or
identity
structures
back
from
the
authentication
modules.
v
Passes
the
statuses
and/or
identity
structures
back
to
the
Base
runtime.
External
authentication
interface
functions
The
use
of
this
interface
to
author
custom
authentication
modules
is
described
in
this
developer
reference.
The
external
authentication
is
often
referred
to
by
the
prefix
used
to
name
its
functions
—
xauthn.
Every
authentication
module
implements
one
or
more
of
four
functions
defined
by
the
external
authentication
module
interface.
This
is
true
both
for
the
built-in
authentication
modules
as
well
as
custom
modules
that
you
can
develop
using
the
ADK.
The
external
authentication
interface
is
described
in
detail
in
Appendix
A,
“External
authentication
C
API
reference,”
on
page
55,
but
briefly
the
four
functions
are:
v
xauthn_initialize()
Initializes
a
specified
authentication
module
shared
library.
v
xauthn_authenticate()
Performs
the
authentication
module
authentication
tasks.
v
xauthn_change_password()
Performs
a
password
change.
v
xauthn_shutdown()
Shuts
down
a
specified
authentication
module
shared
library.
4
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
How
authentication
methods
are
implemented
using
the
authentication
framework
This
section
describes
how
authentication
methods,
and
the
authentication
operations
they
contain,
are
implemented
in
the
Web
security
resource
manager
authentication
framework.
The
following
authentication
methods
are
supported:
v
Basic
authentication
v
Forms
authentication
v
Token
authentication
v
Certificate
authentication
v
HTTP
header
authentication
v
IP
Address
authentication
v
Failover
cookie
authentication
v
Switch
user
authentication
v
SPNEGO
(Kerberos)
authentication
v
Cross-domain
single
sign-on
(token)
v
e-community
single
sign-on
The
following
sections
describe
the
sequence
of
events
or
operations
for
each
major
type
of
authentication
method.
v
“Authentication”
v
“Changing
passwords”
on
page
6
v
“Adding
extended
attributes”
on
page
6
v
“Post
password
change
processing”
on
page
7
v
“Password
strength”
on
page
7
Authentication
The
sequence
of
events
can
vary
depending
on
the
authentication
module.
The
general
sequence
of
events
is
as
follows.
1.
The
Web
security
resource
manager
receives
a
request
containing
authentication
information.
For
example,
a
username
and
password.
2.
The
Web
security
resource
manager
extracts
the
authentication
information
from
the
request.
3.
The
Web
security
resource
manager
passes
the
authentication
information
to
the
Base
runtime.
4.
The
Base
runtime
passes
the
authentication
information
to
the
external
authentication
interface.
5.
The
external
authentication
interface
formats
the
information,
and
then
passes
it
to
an
authentication
module
that
implements
the
external
xauthn_authenticate()
function.
6.
The
authentication
module
performs
the
actual
authentication
and
returns
an
identity
structure
back
to
the
external
authentication
interface.
7.
The
external
authentication
interface
passes
the
identity
structure
back
to
the
Base
runtime.
8.
The
Base
runtime
passes
the
identity
structure
to
the
authorization
API,
which
then
constructs
a
credential
and
returns
it
to
the
Base
runtime.
9.
The
Base
runtime
then
passes
the
credential
back
to
the
Web
security
resource
manager,
for
use
in
authorizing
and
managing
sessions
with
the
user.
Chapter
1.
Web
security
authentication
framework
5
Changing
passwords
The
general
sequence
of
events
is
as
follows.
1.
The
Web
security
resource
manager
receives
a
request
containing
authentication
information.
In
this
example,
an
old
password
and
a
new
password.
2.
The
Web
security
resource
manager
extracts
the
authentication
information
from
the
request.
3.
The
Web
security
resource
manager
passes
the
authentication
information
to
the
Base
runtime.
4.
The
Base
runtime
passes
the
authentication
information
to
the
external
authentication
interface.
5.
The
external
authentication
interface
formats
the
information,
and
then
passes
it
to
an
authentication
module
that
implements
the
xauthn_change_password()
function.
6.
The
authentication
module
performs
the
password
change
operation
and
returns
a
status
to
the
external
authentication
interface.
7.
The
external
authentication
interface
returns
the
status
to
the
Base
runtime.
8.
The
Base
runtime
returns
the
status
to
the
Web
security
resource
manager.
9.
The
Web
security
resource
manager
then
communicates
either
success
or
failure
to
the
user.
Adding
extended
attributes
This
authentication
module
is
chained.
Rather
than
being
called
directly
via
the
interface
from
the
Web
security
resource
manager,
it
is
always
called
(if
configured)
after
the
completion
of
an
authentication
operation
performed
by
another
authentication
module
using
the
xauthn_authenticate()
function.
The
general
sequence
of
events
is
as
follows.
1.
The
Web
security
resource
manager
receives
a
request
containing
authentication
information.
In
this
example,
a
username
and
password.
2.
The
Web
security
resource
manager
extracts
the
authentication
information
from
the
request.
3.
The
Web
security
resource
manager
passes
the
authentication
information
to
the
Base
runtime.
4.
The
Base
runtime
passes
the
authentication
information
to
the
external
authentication
interface.
5.
The
external
authentication
interface
formats
the
information,
and
then
passes
it
to
an
authentication
module
that
implements
the
xauthn_authenticate()
function.
6.
The
authentication
module
performs
the
actual
authentication
and
returns
an
identity
structure
back
to
the
external
authentication
interface.
7.
The
external
authentication
interface
then
passes
the
identity
to
the
Base
runtime.
8.
The
Base
runtime
recognizes
that
an
extended
attribute
module
has
been
configured
and
passes
the
identity
structure
back
through
the
external
authentication
interface
to
the
extended
attributes
authentication
module.
9.
The
extended
attributes
authentication
module
adds
extended
attributes
to
the
identity
structure
and
returns
it
back
to
the
external
authentication
interface.
10.
The
external
authentication
interface
passes
the
identity
structure
back
to
the
Base
runtime.
6
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
11.
The
Base
runtime
passes
the
identity
structure
to
the
authorization
API.
The
authorization
API
constructs
a
credential
and
returns
it
to
the
Base
runtime.
12.
The
Base
runtime
then
passes
the
credential
back
to
the
Web
security
resource
manager,
for
use
in
authorizing
and
managing
sessions
with
the
user.
Post
password
change
processing
This
authentication
module
is
chained.
Rather
than
being
called
directly
through
the
interface
from
the
Web
security
resource
manager,
it
is
always
called
(when
configured)
after
the
completion
of
a
change
password
operation
performed
by
another
authentication
module
using
the
xauthn_change_password()
function.
The
general
sequence
of
events
is
as
follows.
1.
The
Web
security
resource
manager
receives
a
request
containing
authentication
information.
In
this
example,
an
old
password
and
a
new
password.
2.
The
Web
security
resource
manager
extracts
the
authentication
information
from
the
request.
3.
The
Web
security
resource
manager
passes
the
authentication
information
to
the
Base
runtime.
4.
The
Base
runtime
passes
the
authentication
information
to
the
external
authentication
interface.
5.
The
external
authentication
interface
formats
the
information,
and
then
passes
it
to
an
authentication
module
that
implements
the
xauthn_change_password()
function.
6.
The
authentication
module
performs
the
password
change
operation
and
returns
a
status
to
the
external
authentication
interface.
7.
The
external
authentication
interface
returns
the
status
to
the
Base
runtime.
8.
The
Base
runtime
recognizes
that
a
post
password
change
module
has
been
configured.
9.
The
Base
runtime
then
passes
the
authentication
information
to
the
post
password
change
module.
10.
The
module
performs
some
operation,
such
as
synchronizing
the
password
with
an
external
registry,
and
then
returns
a
status
to
the
external
authentication
interface.
11.
The
external
authentication
interface
returns
the
status
to
the
Web
security
resource
manager.
Password
strength
This
authentication
method
was
implemented,
in
previous
versions
of
Tivoli
Access
Manager,
by
a
shared
library.
This
shared
library
has
been
deprecated.
The
authentication
operation
that
was
performed
by
the
shared
library
is
now
performed
within
the
external
authentication
interface.
The
general
sequence
of
events
is
as
follows.
1.
The
Web
security
resource
manager
receives
a
request
containing
authentication
information.
In
this
example,
an
old
password
and
a
new
password.
2.
The
Web
security
resource
manager
extracts
the
authentication
information
from
the
request.
3.
The
Web
security
resource
manager
passes
the
authentication
information
to
the
Base
runtime.
Chapter
1.
Web
security
authentication
framework
7
4.
The
Base
runtime
passes
the
authentication
information
to
the
external
authentication
interface.
5.
The
external
authentication
interface
formats
the
information,
and
then
passes
it
to
an
authentication
module
that
implements
the
xauthn_change_password()
function.
6.
The
xauthn_change_password()
recognizes
that
a
password
strength
check
has
been
implemented.
The
password
strength
check
is
run,
and
decides
whether
the
new
password
satisfies
the
password
strength
policy.
7.
When
the
password
strength
policy
is
satisfied,
the
password
is
changed.
When
the
password
strength
policy
is
not
changed,
the
password
change
is
denied.
The
status
is
returned
to
the
external
authentication
interface.
8.
The
external
authentication
interface
returns
the
status
to
the
Base
runtime.
9.
The
Base
runtime
returns
the
status
to
the
Web
security
resource
manager.
10.
The
Web
security
resource
manager
then
communicates
either
success
or
failure
to
the
user.
8
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
How
to
use
this
developer
reference
The
basic
steps
for
implementing
a
custom
authentication
module
are:
1.
Identify
the
type
of
authentication
method
and
data
that
you
want
to
process.
You
can
write
a
custom
authentication
module
for
any
of
the
authentication
mechanisms
supported
by
WebSEAL
or
the
Plug-in
for
Web
Servers.
Instructions
for
developing
authentication
modules
for
each
type
of
authentication
operation
are
described
in
Chapter
3,
“Customizing
authentication
modules,”
on
page
17.
The
cross-domain
single
sign-on
authentication
module
requires
additional
instructions,
including
the
optional
use
of
the
cross-domain
mapping
framework
API.
This
is
described
in
Chapter
4,
“Cross-domain
single
sign-on
authentication,”
on
page
39.
2.
Build
a
custom
library
using
the
external
authentication
C
API.
For
an
overview
of
the
external
authentication
interface
and
the
cross-domain
mapping
framework,
see
Chapter
2,
“Application
development
kit
overview,”
on
page
11.
Reference
pages
for
each
of
the
external
authentication
interface
functions
are
provided
in
Appendix
A,
“External
authentication
C
API
reference,”
on
page
55.
Reference
pages
for
the
cross-domain
mapping
framework
are
provided
in
Appendix
B,
“Cross-domain
mapping
framework
C
API
reference,”
on
page
65.
3.
Configure
the
Web
security
resource
manager
to
use
the
custom
library
for
the
specified
data.
You
configure
custom
authentication
modules
into
the
secure
Web
server
by
modifying
entries
in
the
secure
Web
server
configuration
file.
This
developer
reference
provides
configuration
instructions
in
Chapter
3,
“Customizing
authentication
modules,”
on
page
17
and
Chapter
4,
“Cross-domain
single
sign-on
authentication,”
on
page
39.
When
you
are
ready
to
configure
a
new
authentication
module
for
WebSEAL,
you
should
also
review
the
detailed
authentication
configuration
information
in
the
IBM
Tivoli
Access
Manager
for
e-business
WebSEAL
Administration
Guide.
To
review
detailed
configuration
information
for
authentication
modules
used
by
the
Plug-in
for
Web
servers,
see
also
the
IBM
Tivoli
Access
Manager
for
e-business
Plug-in
for
Web
Servers
Integration
Guide.
Chapter
1.
Web
security
authentication
framework
9
10
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Chapter
2.
Application
development
kit
overview
The
Web
Security
application
development
kit
provides
two
authentication
APIs
for
use
when
writing
authentication
modules.
The
primary
API
is
the
external
authentication
API.
The
secondary
API
is
the
cross-domain
mapping
framework.
This
API
is
used
to
map
user
identities
from
a
third-party
registry
entry
to
an
identity
known
to
the
Tivoli
Access
Manager
registry.
The
ADK
also
contains
a
password
strength
library
(deprecated)
and
a
demonstration
application
that
can
be
used
to
obtain
examine
credential
information.
In
the
following
sections,
this
chapter
describes
the
contents
of
each
part
of
the
ADK:
v
“External
authentication
API”
on
page
12
v
“Cross-domain
mapping
framework
API”
on
page
13
v
“Password
strength”
on
page
14
v
“EPAC
demonstration
application”
on
page
15
©
Copyright
IBM
Corp.
1999,
2003
11
External
authentication
API
The
Web
security
external
authentication
C
API
is
part
of
the
Web
Security
ADK
package
(PDWebADK).
The
ADK
consists
of
the
following
components:
v
API
header
files
v
API
library
v
Source
file
v
Example
pre-built
authentication
module
library
file
(for
demonstration
only)
v
Makefiles
for
building
custom
libraries
The
authentication
module
and
external
authentication
C
API
components
are
located
in
a
directory
named
pdxauthn_adk.
The
API
components
are
contained
in
the
following
subdirectories:
Directory
Contents
include
Contains
C
header
files:
v
pdxauthn.h
Definition
of
function
prototypes,
client
identity,
and
error
codes
used
for
authentication
API
functions
v
xnvlist.h
User
authentication
data
structure
utility
functions
v
xattr.h
User
extended
attributes
data
structure
utility
functions
lib
Contains
the
authentication
module
authentication
static
library
files:
v
UNIX
systems:
libpdxauthn.a
v
Windows
systems:
pdxauthn.lib
example
Contains:
v
Source
file
(xauthn.c)
for
customization
v
Makefile
v
A
pre-built
platform-specific
example
library
to
demonstrate
a
functional
authentication
module.
12
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Cross-domain
mapping
framework
API
The
cross-domain
mapping
framework
(CDMF)
is
a
programming
interface
you
can
use
to
build
a
custom
library
that
provides
mapping
services
for
a
user
identity
and
handles
any
extended
user
attributes.
The
CDMF
is
used
with
Tivoli
Access
Manager
cross-domain
single
sign-on
solutions.
The
cross-domain
mapping
framework
(CDMF)
API
can
be
found
in
the
Web
Security
ADK
package
(PDWebADK)
and
consists
of
the
following
components:
v
CDMF
API
library
v
API
header
file
v
Demonstration
CDMF
file
v
Makefiles
The
CDMF
components
are
located
in
a
directory
named
cdmf_adk.
The
following
table
lists
the
files
included
in
this
directory:
Files
Description
cdmf.c.skeleton
The
source
file
that
can
be
customized
by
the
developer
to
implement
the
CDMF
logic.
This
file
needs
to
be
renamed
to
cdmf.c
and
then
compiled
and
linked
into
the
CDMF
library.
cdmf.c.example
Example
cdmf.c
file
This
example
performs
a
simple
user
mapping
and
performs
some
manipulation
of
the
CDSSO
attribute
lists.
cdmf.h
The
header
file
for
cdmf.c.
cdmf_utils.h
The
header
file
providing
utility
functions
for
manipulating
extended
user
attribute
lists.
cdssotypes.h
The
header
file
that
provides
definitions
of
types
and
macros
used
in
cdmf.c.
Windows
only:
cdmf_utils.lib
The
library
for
the
utility
functions
in
cdmf_utils.h.
Makefile.win32
The
nmake
Makefile
used
to
build
the
custom
CDMF
library.
UNIX
only:
libcdmfutils.
(so,
a,
sl)
The
library
for
the
utility
functions
defined
in
cdmf_utils.h.
-
.so
for
Solaris
-
.a
for
AIX
-
.sl
for
HP-UX
Makefile.cdmf.in
The
template
Makefile
used
to
build
the
CDMF
library.
Change
this
file
to
suit
your
platform.
Chapter
2.
Application
development
kit
overview
13
Password
strength
Attention:
This
implementation
method
for
password
strength
has
changed
for
Version
5.1.
The
password
strength
library
is
deprecated,
and
is
supplied
only
for
backwards
compatibility.
The
new
implementation
method
is
described
in
“Password
strength
checking”
on
page
32.
Password
strength
refers
to
the
stipulations
placed
on
the
construction
of
a
password
by
password
policy
rules.
Tivoli
Access
Manager
provides
two
means
of
controlling
password
strength
policy:
v
Five
pdadmin
password
policy
commands
v
A
plugable
authentication
module
that
allows
you
to
customize
a
password
policy
Tivoli
Access
Manager
provides
resources
that
allow
you
to
customize
your
password
strength
policy.
Password
strength
policy
module
conditions:
v
The
module
is
only
called
when
a
password
is
changed
via
the
pkmspasswd
command.
The
module
is
not
called
if
passwords
are
created
or
changed
using
the
Web
portal
manager
or
the
pdadmin
utility.
v
The
module
should
be
a
supplement,
not
a
replacement,
to
the
five
standard
pdadmin
policy
parameters.
Refer
to
the
IBM
Tivoli
Access
Manager
for
e-business
Command
Reference
for
information
on
the
pdadmin
policy
commands.
v
The
password
strength
module
is
checked
before
the
pdadmin
policy
parameters.
Examples
of
custom
password
policies:
v
Performing
checks
against
a
database
of
previously
used
passwords
(history)
v
Performing
a
dictionary
look-up
to
prevent
use
of
a
word
commonly
used
in
a
language
14
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
EPAC
demonstration
application
The
Web
Security
application
development
kit
contains
a
CGI
program
that
reads
information
that
is
stored
in
the
form
of
extended
privilege
attribute
certificate
(EPAC)
and
converts
it
to
a
Tivoli
Access
Manager
user
credential.
The
PAC
is
obtained
from
the
HTTP_IV_CREDS
variable.
In
addition,
the
program
displays
the
name
and
value
for
each
credential
attribute
contained
in
the
PAC.
The
application
development
kit
contains
the
following
files:
File
Description
epac
The
demonstration
program
epac.c
Source
for
the
demonstration
program
Makefile.in
Makefile
(for
use
when
building
the
program)
README
A
text
file
containing
instructions
for
how
to
build
and
configure
the
program.
The
EPAC
uses
the
Tivoli
Access
Manager
authorization
API.
To
use
the
authorization
API,
you
must
install
the
Tivoli
Access
Manager
authorization
ADK
package
(PDAuthADK).
You
can
use
the
EPAC
demonstration
binary
as
distributed,
or
you
can
modify
the
source
to
customize
it
for
your
deployment.
The
source
uses
a
number
of
authorization
API
function
calls.
You
can
find
more
information
on
these
functions
in
the
IBM
Tivoli
Access
Manager
for
e-business
Authorization
C
API
Developer
Reference.
The
EPAC
source
contains
a
utility
function
for
writing
debug
output
to
a
log
file,
and
a
utility
function
for
formatting
the
output
of
the
credential
attribute
list
into
an
HTML
table.
You
can
use
these
functions
as
written,
or
edit
them
to
modify
the
output
format.
The
following
table
describes
the
credential
attributes
that
are
displayed
by
the
EPAC
program:
Attribute
name
Description
AUTHENTICATION_LEVEL
Authentication
mechanism
level,
in
terms
of
authentication
strength
policy.
For
example:
1
AZN_CRED_AUTH_METHOD
The
authentication
method
used.
For
example:
password
AZN_CRED_AUTHNMECH_INFO
Information
about
the
authentication
mechanism.
For
example:
LDAP
Registry
AZN_CRED_AUTHZN_ID
User
identity.
For
example,
for
an
LDAP
user
registry:
cn=joeuser,o=ibm,c=us
AZN_CRED_BROWSER_INFO
Information
identifying
the
type
and
version
of
browser
AZN_CRED_GROUPS
Group
identifiers,
in
UUID
format
Chapter
2.
Application
development
kit
overview
15
AZN_CRED_GROUPS_NAMES
Group
names,
in
user
registry
format.
For
example:
cn=sales,o=ibm,c=us
AZN_CRED_IP_ADDRESS
IP
address
(hex
number)
AZN_CRED_LDAP_DN
LDAP
DN
for
the
user
(principal)
AZN_CRED_MECH_ID
User
registry
mechanism
ID.
For
example:
IV_LDAP_V3.0
AZN_CRED_PRINCIPAL_NAME
User
name
AZN_CRED_PRINCIPAL_UUID
User
identity,
expressed
as
a
Universal
Unique
Identifier
AZN_CRED_QOP_INFO
Quality
of
protection
setting
AZN_CRED_VERSION
Credential
version
(indicates
release
of
Tivoli
Access
Manager).
To
use
the
EPAC
demo,
complete
the
following
steps:
1.
Build
the
EPAC
CGI
executable.
2.
Configure
the
EPAC
as
an
authorization
API
application.
3.
Deploy
and
run
the
EPAC
executable.
For
more
information
on
each
of
the
above
steps,
see
the
README
file
that
accompanies
the
EPAC
source
file.
16
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Chapter
3.
Customizing
authentication
modules
Topic
index:
v
“Using
the
external
authentication
API”
on
page
18
v
“User
authentication”
on
page
24
v
“Change
user
password”
on
page
29
v
“Add
extended
attributes
to
the
credential”
on
page
30
v
“Password
strength
checking”
on
page
32
v
“Post
password
change
processing”
on
page
33
v
“UTF-8
compatibility”
on
page
34
v
“Authentication
module
configuration”
on
page
37
©
Copyright
IBM
Corp.
1999,
2003
17
Using
the
external
authentication
API
The
authentication
module
developer
determines
the
specific
operations
to
include
in
a
customized
authentication
module.
Each
authentication
module
is
built
around
a
set
of
interfaces
provided
in
the
external
authentication
C
API.
Some
authentication
modules
also
use
the
interfaces
found
in
the
cross-domain
mapping
framework
API.
As
an
authentication
module
developer,
you
combine
the
supplied
interface
calls
with
your
own
code
that
performs
the
specific
authentication
tasks
required
for
your
specific
deployment.
To
prepare
for
writing
an
authentication
module,
complete
the
following
tasks:
v
Review
the
description
of
the
external
authentication
API
in
the
sections
that
follow.
v
Review
the
sample
source
code
(xauthn.c)
provided
with
the
WebSEAL
application
development
kit.
This
section
contains
the
following
topics:
v
“Software
requirements”
v
“Build
instructions”
v
“Example
library”
on
page
19
v
“API
functions
and
data
types”
on
page
20
Software
requirements
The
Web
Security
application
development
kit
provides
all
the
necessary
resources
for
authentication
module
application
development.
To
develop
and
test
a
authentication
module
application
on
a
single
machine,
the
following
Tivoli
Access
Manager
components
must
be
installed:
v
Tivoli
Access
Manager
runtime
(PDRTE)
v
Tivoli
Access
Manager
policy
server
(PDMgr)
v
Tivoli
Access
Manager
authorization
ADK
(PDAuthADK)
v
Tivoli
Access
Manager
WebSEAL
(PDWeb)
Note:
Deployments
based
on
the
Plug-in
for
Web
Servers
can
use
the
Tivoli
Access
Manager
Plug-in
for
Web
Servers
instead
of
WebSEAL.
v
Tivoli
Access
Manager
Web
Security
ADK
(PDWebADK)
For
instructions
regarding
installation
and
configuration
of
Tivoli
Access
Manager
components,
refer
to
the
IBM
Tivoli
Access
Manager
for
e-business
Web
Security
Installation
Guide.
Build
instructions
You
build
a
authentication
module
library
by
using
make
to
compile
your
source
file.
The
WebSEAL
application
development
kit
provides
a
sample
Makefile
Makefile.in
under
the
example
directory.
In
many
cases,
you
can
use
the
Makefile
with
minimum
changes.
The
Makefile
template
is
written
to
compile
the
example
source
file
xauthn.c.
See
the
Makefile.in
template
for
more
information.
18
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
When
compiling
the
library,
add
the
include
directory
of
the
Web
Security
application
development
kit
to
the
compiler
command
line.
When
linking
the
library,
include
the
appropriate
pdxauthn
library.
See
“External
authentication
API”
on
page
12.
Example
library
The
Tivoli
Access
Manager
Web
security
ADK
includes
an
example
(demonstration)
library
that
implements
a
generic
username
and
password
authentication
module.
The
sample
library
is
an
interactive
program
that
displays
all
the
available
client
authentication
data
and
prompts
for
a
user
identity.
In
addition,
the
example
library
can
be
used
as
an
extended
attributes
authentication
module.
In
this
case,
the
prompts
ask
for
tag/value
data
instead
of
client
authentication
data.
The
example
library
is
located
in
the
example
directory
of
the
application
development
kit
(PDWebADK)
package.
To
use
the
sample
library
with
WebSEAL,
configure
WebSEAL
as
described
in
“Authentication
module
configuration”
on
page
37.
Then
use
the
sample
library,
run
the
Tivoli
Access
Manager
Web
security
resource
manager
(WebSEAL
or
the
Plug-in
for
Web
Servers)
in
the
foreground.
For
example,
on
a
Solaris
system:
WebSEAL
#
/opt/pdweb/bin/webseald
-foreground
Plug-in
for
Web
Servers
#
/opt/pdwebpi/bin/pdwebpi
-foreground
The
program
user
interface
for
client
authentication
data
for
the
WebSEAL
version
of
the
application
appears
as
follows:
---------------------------------------------------------
Access
Manager
WebSEAL
Version
5.1
(Build
010904)
Copyright
(C)
IBM
Corporation
2000-2002
All
Rights
Reserved.
==============================
User
Authentication
Information:
==============================
xauthn_username:
charles
(7)
xauthn_password:
abcdefgh
(8)
xauthn_ipaddr:
127.0.0.1
(9)
xauthn_qop:
SSK:
SSLV3:
04
(14)
xauthn_browser_info:
Mozilla/4.7
[en]
(WinNT;
U)
(27)
Enter
the
user
identity:
testuser
---------------------------------------------------------
The
user
identity
(testuser
in
the
example
above)
is
returned
to
WebSEAL.
The
program
user
interface
for
tag/value
data
appears
as
follows:
---------------------------------------------------------
Access
Manager
WebSEAL
Version
5.1
(Build
010904)
Copyright
(C)
IBM
Corporation
2000-2002
All
Rights
Reserved.
==============================
User
Authentication
Information:
==============================
Chapter
3.
Customizing
authentication
modules
19
xauthn_username:
charles
(7)
xauthn_password:
abcdefgh
(8)
xauthn_ipaddr:
127.0.0.1
(9)
xauthn_qop:
SSK:
SSLV3:
04
(14)
xauthn_browser_info:
Mozilla/4.7
[en]
(WinNT;
U)
(27)
Using
existing
name:
testuser
Enter
the
test
tag:
<tag>
Enter
the
test
tag
data:
<value>
---------------------------------------------------------
API
functions
and
data
types
The
following
table
lists
the
external
authentication
API
functions.
The
first
column
contains
links
to
the
reference
page
for
each
function.
The
second
column
contains
links
to
sections
in
this
developer’s
reference
that
describe
the
tasks
for
which
this
function
is
called.
Table
1.
External
authentication
API
functions
Function
Task
“xauthn_initialize()”
on
page
61
“Initializing
and
shutting
down
the
API”
“xauthn_authenticate()”
on
page
59
v
“Obtain
user
authentication
information”
on
page
24
v
“Authenticate
the
user
identity”
on
page
28
v
“Return
user
identity”
on
page
28
“xauthn_change_password()”
on
page
60
v
“Change
user
password”
on
page
29
v
“Password
strength
checking”
on
page
32
v
“Post
password
change
processing”
on
page
33
“xauthn_shutdown()”
on
page
62
“Initializing
and
shutting
down
the
API”
“xauthn_util_entry_to_creds()”
on
page
63
“Convert
the
credential
to
string
format”
on
page
28
“xattr_get()”
on
page
57
“Add
extended
attributes
to
the
credential”
on
page
30
“xattr_set()”
on
page
58
“xnvlist_get()”
on
page
56
“Obtain
user
authentication
information”
on
page
24
The
pdxauthn
static
library
file
contains
the
utility
functions.
To
use
these
utilities,
you
must
link
your
custom
shared
library
to
this
file:
Table
2.
File
names
of
pdxauthn
libraries
Operating
system
Filename
UNIX
libpdxauthn.a
Windows
pdxauthn.lib
Initializing
and
shutting
down
the
API
WebSEAL
loads
the
authentication
module
library
and
initializes
it
by
calling
xauthn_initialize().
20
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
This
function
contains
the
argc
and
argv
parameters.
These
parameters
contain
the
values
specified
in
the
library
definition
located
in
the
Web
security
resource
manager
(WebSEAL
or
Plug-in
for
Web
Servers)
configuration
file.
The
library
definition
uses
the
following
syntax:
authentication_mechanism
=
library_name[&arg1]...[
argN]
The
library
definition
defines
all
entries
after
the
ampersand
character
(&)
to
be
initialization
parameters.
Unlike
the
C
language
argv,
the
argv[0]
array
entry
is
the
first
parameter.
For
more
information,
see
the
reference
page
for
xauthn_initialize().
It
is
not
necessary
to
shutdown
the
external
authentication
API.
The
API
provides
a
shutdown
function,
xauthn_shutdown().
However,
the
shutdown
interface
is
not
functional
in
Tivoli
Access
Manager
5.1.
You
can
successfully
complete
and
use
an
authentication
module
implementation
without
it.
Extended
attributes
Extended
attributes
contain
information
about
a
user.
This
information
consists
of
name/value
pairs.
A
series
of
name/value
pairs
can
be
organized
into
a
list.
This
list
is
used
by
xauthn_authenticate()
to
pass
extended
information
about
a
user
to
the
custom
authentication
module
library.
The
data
structure
that
holds
a
single
extended
attribute
is
xattr_list_item_t.
typedef
struct
{
char
*name;
char
*value;
}
xattr_list_item_t;
Table
3.
Members
of
the
extended
attribute
item
data
structure
Member
Description
name
A
string
representing
the
name
of
the
extended
attribute.
value
A
string
representing
the
value
of
the
extended
attribute.
The
data
type
xattr_list_t
is
a
list
of
extended
attributes
to
be
added
to
the
credential.
typedef
struct
{
long
length;
xattr_list_item_t
*items;
}
xattr_list_t;
Table
4.
Members
of
the
extended
attribute
list
data
structure
Member
Description
length
The
number
of
elements
in
the
list.
items
An
array
of
xttr_list_item_t
structures
User
identity
information
The
xauthn_identity_t
data
structure
used
to
hold
information
about
a
user’s
Tivoli
Access
Manager
identity.
typedef
struct
{
struct
{
unsigned32
prin_type;
union
{
/*
case(s):
0
*/
char
*name;
Chapter
3.
Customizing
authentication
modules
21
/*
case(s):
1
*/
char
*dn;
/*
case(s):
2
*/
char
*uraf_name;
}
data;
}
prin;
char
*user_info;
char
*authnmech_info;
xattr_list_t
xattrs;
}
xauthn_identity_t;
Table
5.
Members
of
the
user
identity
data
structure
Member
Description
prin_type
The
prin_type
indicates
the
user
registry
used
to
generate
a
credential
from
the
identity.
The
only
valid
value
is
XAUTHN_PRIN_TYPE_DN
(LDAP
user
registry),
where
the
prin.data.dn
contains
the
distinguished
name
(DN)
of
the
user.
name
Not
valid.
dn
The
user’s
LDAP
Distinguished
Name
(DN)
or
the
LDAP
user
name.
uraf_name
Not
valid
user_info
Information
added
to
the
credential
as
an
extended
attribute
called
azn_cred_user_info.
authnmech_info
Authentication
method
information.
Added
to
the
credential
as
an
extended
attribute
called
azn_cred_mech_id.
xattrs
The
xattr_list_t
data
structure
can
be
used
to
return
any
extended
user
attributes.
Authentication
data
The
xnvlist_item_t
data
structure
holds
a
single
item
of
authentication
data.
typedef
struct
{
char
*name;
char
*value;
int
vlen;
}
xnvlist_item_t;
Table
6.
Members
of
the
data
structure
for
authentication
data
Member
Description
name
A
string
representing
the
name
of
the
item.
Valid
names
are
described
in
“Obtain
user
authentication
information”
on
page
24
value
An
array
of
bytes
representing
the
value
of
the
item.
The
authentication
data
can
be
a
character
string
or
can
be
binary
data.
vlen
An
integer
value
containing
the
length
of
the
″value″
array.
The
xnvlist_item_t
data
structure
holds
a
list
of
xnvlist_item_t
authentication
data
structures.
typedef
struct
{
long
length;
xnvlist_item_t
*items;
}
xnvlist_t;
Table
7.
Members
of
the
data
structure
for
a
list
of
authentication
data
items
Member
Description
length
The
number
of
elements
in
the
items
array.
22
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Table
7.
Members
of
the
data
structure
for
a
list
of
authentication
data
items
(continued)
items
An
array
of
xnvlist_item_t.
Chapter
3.
Customizing
authentication
modules
23
User
authentication
The
xauthn_authenticate()
interface
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
WebSEAL
or
the
Plug-in
for
Web
Servers.
The
xauthn_authenticate()
function
is
called,
for
example,
after
you
have
obtained
a
user
name
from
the
user
(if
one
has
not
been
passed
in
already)
and
obtained
the
user
registry
type.
For
another
example,
the
library
could
accept
a
digital
certificate,
modify
the
Distinguished
Name
(DN)
data,
and
return
the
modified
DN
as
the
Tivoli
Access
Manager
identity.
This
section
describes
how
to
complete
the
following
steps:
1.
“Obtain
user
authentication
information”
2.
“Authenticate
the
user
identity”
on
page
28
3.
“Return
user
identity”
on
page
28
Obtain
user
authentication
information
Once
the
authentication
module
library
is
configured,
the
Tivoli
Access
Manager
Web
security
resource
manager
passes
the
client
request
to
the
library
through
the
xauthn_authenticate()
interface.
The
Web
security
resource
manager
can
pass
a
variety
of
client
authentication
information
to
the
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().
The
following
sections
list
the
identifiers
that
contain
authentication
information:
v
“Identifiers
common
to
all
authentication
methods”
v
“Username/password
authentication
identifiers”
on
page
25
v
“Certificate
authentication
identifiers”
on
page
25
v
“Token
card
authentication
identifiers”
on
page
26
v
“HTTP
authentication
identifiers”
on
page
26
v
“Switch
user
authentication
identifiers”
on
page
26
Identifiers
common
to
all
authentication
methods
All
Tivoli
Access
Manager
authentication
methods
use
a
common
set
of
identifiers.
Combine
the
identifiers
in
the
following
set
with
the
identifiers
that
are
specific
to
the
authentication
method
for
your
authentication
module.
The
identifiers
specific
to
authentication
methods
are
described
in
separate
sections
that
follow
this
one.
Table
8.
Identifiers
common
to
all
authentication
methods
Name
Description
XAUTHN_BROWSER_INFO
Browser
information
Example:"Mozilla/4.0
(Compatible;
MSIE
6.0;
Windows
NT
5.0)"
24
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Table
8.
Identifiers
common
to
all
authentication
methods
(continued)
XAUTHN_EXISTING_CRED
Used
only
for
reauthentication.
This
contains
the
user’s
existing
credential
as
a
string.
Example:
″0123456″
XAUTHN_IPADDR
User
IP
address.
For
example:
11.22.33.44
XAUTHN_QOP
Quality
of
protection.
The
format
is
authentication_method:version:cipher_used
The
quality
of
protection
for
Plug-in
for
Web
Servers
is
always
none.
Username/password
authentication
identifiers
Username/password
authentication
uses
the
set
of
identifiers
common
to
all
authentication
methods
(see
Table
8
on
page
24)
plus
a
set
of
identifiers
that
are
specific
to
username/password.
The
following
table
lists
the
specific
identifiers:
Table
9.
Identifiers
specific
to
username-password
authentication
Name
Description
XAUTHN_USERNAME
User
name.
Example:
testuser
XAUTHN_PASSWORD
User
password
XAUTHN_NEW_PASSWORD
User
new
password.
Used
only
for
the
xauthn_change_password()
function.
XAUTHN_METHOD
User
authentication
method.
Used
only
for
xauthn_change_password(),
as
a
password
strength
server.
common
identifiers
See
Table
8
on
page
24
Certificate
authentication
identifiers
Certificate
authentication
uses
the
set
of
identifiers
common
to
all
authentication
methods
(see
Table
8
on
page
24)
plus
a
set
of
identifiers
that
are
specific
to
certificate
authentication.
The
following
table
lists
the
specific
identifiers:
Table
10.
Identifiers
for
X.509
certificate
authentication
Name
Description
XAUTHN_CERT
The
certificate
body,
in
DER
format.
Example:
(binary
data)
XAUTHN_CERT_DN
The
certificate’s
DN.
Example:
cn=testuser,o=tivoli,c=us
XAUTHN_CERT_ISSUER_DN
The
issuer’s
(certificate
authority)
DN.
Example:
CN=issuer,o=tivoli,c=sus
common
identifiers
See
Table
8
on
page
24
Chapter
3.
Customizing
authentication
modules
25
Token
card
authentication
identifiers
Token
card
authentication
uses
the
set
of
identifiers
common
to
all
authentication
methods
(see
Table
8
on
page
24)
plus
a
set
of
identifiers
that
are
specific
to
token
card
authentication.
The
following
table
lists
the
specific
identifiers:
Table
11.
Identifiers
for
token
card
authentication
Name
Description
XAUTHN_USERNAME
User
name.
Example:
testuser
XAUTHN_METHOD
User
authentication
method.
Used
only
for
xauthn_change_password(),
as
a
password
strength
server.
XAUTHN_TOKEN
User
token
(passcode).
This
functions
like
a
password.
Example:
″0123″
XAUTHN_PASSWORD
User’s
current
passcode.
Used
only
for
the
xauthn_change_password()
function.
XAUTHN_NEW_PASSWORD
User’s
new
PIN.
Used
only
for
the
xauthn_change_password()
function.
common
identifiers
See
Table
8
on
page
24
HTTP
authentication
identifiers
HTTP
authentication
uses
the
set
of
identifiers
common
to
all
authentication
methods
(see
Table
8
on
page
24)
plus
a
set
of
identifiers
that
are
specific
to
HTTP
authentication.
The
following
table
lists
the
specific
identifiers:
Table
12.
HTTP
header
authentication
methods
Name
Description
Request_URI
The
request
URI.
This
name
is
a
literal
string,
not
a
variable.
header_name
HTTP
header
name.
The
format
of
the
xnvlist_t
data
structure
differs
for
the
HTTP
header
authentication
method.
The
header_name
stored
in
xnvlist_t
is
the
header
name
specified
in
the
[auth-headers]
stanza
of
the
WebSEAL
configuration
file.
The
value
is
the
authentication
information
passed
through
a
that
header.
common
identifiers
See
Table
8
on
page
24
Switch
user
authentication
identifiers
An
existing
authentication
module
often
returns
additional
information
about
the
user
that
is
incorporated
into
the
user’s
credential.
If
you
are
using
the
switch
user
feature
in
such
an
environment,
you
must
write
a
special
switch
user
authentication
module
that
emulates
the
behavior
of
your
existing
authentication
module
while
supporting
the
requirement
of
returning
a
credential
without
requiring
the
user
password
for
input.
The
Tivoli
Access
Manager
external
authentication
interface
provides
a
set
of
identifiers
that
can
be
used
to
pass
client
authentication
information
to
the
switch
user
authentication
module
library.
This
information
is
passed
using
a
name/value
list
format,
where
the
name
is
an
identifier
that
specifies
the
value
type.
Tivoli
Access
Manager
supports
switch-user
authentication
for
password,
token
card,
certificate,
HTTP
request,
and
single
sign-on
token
authentication
methods.
26
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
For
more
information
on
switch
user
authentication,
including
configuration
instructions,
see
the
IBM
Tivoli
Access
Manager
for
e-business
WebSEAL
Administration
Guide.
The
following
authentication
data
identifiers
are
valid
for
all
of
the
switch-user
authentication
methods:
Table
13.
Valid
identifiers
for
switch-user
authentication
methods
Identifiers
for
switch-user
authentication
methods
Name
Value
XAUTHN_SU_METHOD
Specifies
the
type
of
switch-user
authentication
method.
Must
be
one
of
the
following
values:
v
su-password
Username/password
authentication
v
su-token-card
Token
authentication
v
su-certificate
X.509
certificate
authentication
v
su-http-request
HTTP
header
authentication
v
su-cdsso
Cross-domain
single
sign-on
authentication.
XAUTHN_ADMIN_NAME
The
user
name
of
the
administrator
attempting
to
switch
user.
For
example:
sec_master
XAUTHN_ADMIN_CRED
The
credential
of
the
administrator
attempting
to
switch
user,
as
a
string.
The
xauthn_admin_cred
entry
in
the
xnvlist_t
authentication
data
structure
contains
an
encoded
Tivoli
Access
Manager
credential.
Use
the
xauthn_util_entry_to_creds()
function
to
access
the
credential.
An
example
of
how
to
use
the
function
is
included
in
the
source
code
for
the
sample
xauthn
application.
XAUTHN_EXISTING_CRED
During
reauthentication,
the
credential
of
the
″switched-to″
user,
as
a
string
The
xauthn_existing_cred
entry
in
the
xnvlist_t
authentication
data
structure
contains
an
encoded
Tivoli
Access
Manager
credential.
Use
the
xauthn_util_entry_to_creds()
function
to
access
the
credential.
An
example
of
how
to
use
the
function
is
included
in
the
source
code
for
the
sample
xauthn
application.
XAUTHN_USERNAME
The
user
name
of
the
″switched-to″
user:
For
example:
test-user
Chapter
3.
Customizing
authentication
modules
27
Table
13.
Valid
identifiers
for
switch-user
authentication
methods
(continued)
XAUTHN_IPADDR
Administrator
IP
address
This
data
is
supplied
for
any
authentication
module
that
must
perform
additional
validations
of
the
administrator’s
account.
For
example:
11.22.33.44
XAUTHN_QOP
Administrator
quality
of
protection.
The
format
is
authentication_method:version:cipher_used
Examples:
"x509:TLSv1:04"
"SSK:SSVV3:05"
This
data
is
supplied
for
any
authentication
module
that
must
perform
additional
validations
of
the
administrator’s
account.
The
quality
of
protection
for
Plug-in
for
Web
Servers
is
always
none.
XAUTHN_BROWSER_INFO
Administrator
browser
information
This
data
is
supplied
for
any
authentication
module
that
must
perform
additional
validations
of
the
administrator’s
account.
Example:"Mozilla/4.0
(Compatible;
MSIE
6.0;
Windows
NT
5.0)"
Authenticate
the
user
identity
Authenticate
the
user
against
the
registry.
Convert
the
credential
to
string
format
This
step
is
optional.
This
step
is
necessary
only
when
the
user
has
previously
authenticated,
and
is
now
reauthenticating
in
order
to
be
granted
additional
access
privileges.
In
this
case,
the
user
credential
was
obtained
during
the
previous
authentication.
The
credential
is
passed
in
to
xauthn_authenticate()
user
information
as
xauthn_existing_cred.
If
the
xnvlist_t
item
contains
the
xauthn_existing_cred
item,
use
xauthn_util_entry_to_creds()
to
convert
the
entry
to
a
credential,
as
an
azn_creds_h_t.
Return
user
identity
The
authentication
module
library
is
required
to
return
the
resulting
client
identity
back
to
WebSEAL
or
the
Plug-in
for
Web
Servers.
The
client
identity
is
defined
by
the
xauthn_identity_t
data
structure.
This
structure
is
returned
by
xauthn_authenticate().
28
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Change
user
password
This
step
is
optional.
The
xauthn_change_password()
interface
allows
the
user
to
make
changes
to
the
account
password
that
is
stored
in
the
third-party
user
registry.
The
username/password
and
token
authentication
methods
support
this
function.
If
the
external
authentication
mechanism
you
are
going
to
implement
does
not
support
password
changes,
this
function
should
return:
XAUTHN_S_UNSUPPORTED_AUTHN_METHOD
User
authentication
information
is
passed
to
this
interface
in
a
name/value
data
list
(xnvlist_t).
The
data
list
contains
the
user’s
name,
old
password
or
passcode,
the
new
password
or
PIN,
and
the
authentication
method.
The
authentication
information
identifiers
for
username/password
and
token
authentication
are
described
in
“Obtain
user
authentication
information”
on
page
24.
This
section
describes
the
identifiers
used
by
xauthn_change_password().
See
also
the
reference
page:“xauthn_change_password()”
on
page
60
Chapter
3.
Customizing
authentication
modules
29
Add
extended
attributes
to
the
credential
The
Tivoli
Access
Manager
external
authentication
interface
allows
you
to
add
extended
attribute
data
(business
entitlements)
to
a
user
credential.
These
business
entitlements
can
be
used
in
any
situation
where
this
type
of
data
is
required.
For
example,
entitlement
data
can
be
extracted
from
the
credential
directly
by
an
application
using
the
Authorization
API
or
inserted
in
the
HTTP
headers
of
requests
directed
across
a
junction
to
a
back-end
application
server.
Note:
The
Tivoli
Access
Manager
authorization
API
provides
a
built-in
entitlements
service
that
you
can
use
to
place
extended
attributes
into
a
user
credential.
For
most
deployments,
this
service
can
provide
all
the
functions
necessary
to
modify
user
credentials
to
satisfy
the
deployment’s
security
policy.
In
these
cases,
you
do
not
need
to
write
customized
authentication
module.
For
more
information
on
built-in
entitlements
services,
see
the
IBM
Tivoli
Access
Manager
for
e-business
Authorization
C
API
Developer
Reference.
The
structure
of
the
returned
client
identity
(xauthn_identity_t)
allows
you
to
specify
extended
attribute
information.
This
additional
information
becomes
part
of
the
resulting
Tivoli
Access
Manager
credential.
You
define
extended
attribute
information
with
the
xattr_list_t
data
structure.
Extended
attributes
are
added
by
second
authentication
module
that
is
chained
to
a
built-in
or
custom
authentication
module.
The
initial
authentication
module
creates
the
Tivoli
Access
Manager
identity
and
can
optionally
(in
the
case
of
a
custom
authentication
module)
include
extended
attribute
data.
The
second
authentication
module
in
the
chain
is
used
only
to
add
extended
attribute
data.
Extended
attributes
must
be
added
to
the
credential
at
the
time
of
authentication.
The
extended
attribute
list
can
only
be
used
to
pass
string
values.
Binary
data
cannot
be
used.
Each
name/value
pair
must
be
added
to
the
identity
via
a
call
to
the
xattr_set()
function
and
can
be
retrieved
using
the
xattr_get()
function.
In
order
for
WebSEAL
to
recognize
the
extended
attribute
as
tag/value
data,
the
tag
name
is
prefixed
with
the
macro
XAUTHN_TAG_VALUE_PREFIX,
which
is
defined
as
″tagvalue_″.
The
following
section
of
the
xauthn.c
demo
program
illustrates
this
action:
char
*tag
=
(char
*)
malloc(1024+XAUTHN_TAG_VALUE_KEY_PREFIX+1);
char
*tag_data
=
(char
*)
malloc(1024);
if
(!XAUTHN_TAG_VALUE_KEY_PREFIX
||
!tag
||
!tag_data)
(
/*
Error
condition
*/
return;
)
/*
Request
the
tag
name
*/
sprintf(tag,
"%s",
XAUTHN_TAG_VALUE_KEY_PREFIX);
printf("Enter
the
test
tag:
");
fflush(stdout);
scanf("%1024s",
tag
+
strlen(XAUTHN_TAG_VALUE_KEY_PREFIX));
/*
Request
the
tag
data
*/
printf("Enter
the
test
tag
data:
");
fflush(stdout);
scanf("%1024s",
tag_data);
/*
Add
the
tag/value
pair
to
the
credential*/
xattr_set(&ident->xattrs,
tag,
tag_data);
30
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
The
following
example
illustrates
a
method
of
calling
xattr_set
to
supply
tag/value
data
(business
entitlements)
in
a
custom
authentication
module:
char
*name
=
strdup("tagvalue_ldap_employee_number");
char
*value
=
strdup("12345678");
if
(name
&&
value)
{
xattr_set
(&ident->xattrs,
name,
value);
}
else
{
/*
handle
strdup
failures
here
*/
}
name
=
strdup("tagvalue_ldap_employee_phone");
value
=
strdup("888-888-8888");
if
(name
&&
value)
{
xattr_set
(&ident->xattrs,
name,
value);
}
else
{
/*
handle
strdup
failures
here
*/
}
Chapter
3.
Customizing
authentication
modules
31
Password
strength
checking
The
previous
section
in
this
chapter
described
how
to
use
the
xauthn_change_password()
interface
to
change
a
user’s
password.
Alternatively,
the
xauthn_change_password()
interface
can
be
used
to
implement
a
password
strength
server.
This
can
be
done
in
an
authentication
module
without
using
the
function
to
change
a
password.
When
writing
an
authentication
module
for
this
task,
the
xauthn_initialize()
and
xauthn_shutdown()
serve
their
normal
purpose
for
the
password
strength
server.
The
xauthn_authenticate()
function
call
can
be
stubbed
out.
The
authentication
method
is
passed
to
this
interface
among
the
user
authentication
information.
This
enables
the
password
strength
server
to
pass
policy
based
on
the
type
of
method
with
which
the
user
authenticated.
User
authentication
information
is
passed
to
this
interface
in
a
name/value
data
list
(xnvlist_t).
The
data
list
contains
the
user’s
name,
old
password
or
passcode,
the
new
password
or
PIN,
and
the
authentication
method.
When
writing
an
authentication
module
to
perform
password
strength
checking,
use
the
information
returned
in
the
xnvlist_t
as
input
to
your
specific
password
checking
code.
For
example,
this
could
be
a
check
to
ensure
that
token
authentication
is
used.
The
authentication
information
identifiers
for
each
authentication
method,
including
those
that
are
specific
to
xauthn_change_password()
are
described
in
“Obtain
user
authentication
information”
on
page
24.
For
more
information,
see
the
reference
page
for
xauthn_change_password().
32
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Post
password
change
processing
Post
password
change
processing
is
supported
by
both
WebSEAL
and
the
Plug-in
for
Web
Servers.
This
section
refers
to
both
of
these
components
as
the
Tivoli
Access
Manager
Web
security
resource
manager.
The
Web
security
resource
manager
provide
support
for
customized
post
password
change
processing.
An
authentication
module
can
be
written
to
be
called
after
a
password
is
successfully
changed
through
the
Web
security
resource
manager
by
using
the
pkms
password
change
page.
This
feature
enables
passwords
in
external
user
registries,
which
may
be
unknown
to
Tivoli
Access
Manager,
to
be
updated
with
passwords
that
the
user
changed
during
the
course
of
attempting
authentication
when
challenged
by
the
Web
security
resource
manager.
When
a
user’s
password
is
successfully
changed,
the
Web
security
resource
manager
checks
the
authentication
mechanism
that
is
in
use
to
see
if
it
is
enabled
for
post
password
change
processing.
When
it
is
enabled,
the
Web
security
resource
manager
loads
the
shared
library
containing
the
custom
authentication
module
and
calls
it.
The
post
password
change
module
uses
the
external
authentication
interface.
The
authentication
module
for
post
password
change
processing
must
include:
v
xauthn_initialize()
v
xauthn_change_password()
The
xauthn_change_password()
function
is
called
with
an
xnvlist_t
structure
as
an
input
parameter.
The
xnvlist_t
contains
the
following
data:
v
Name
of
the
user
who
needs
the
password
to
be
changed
v
User’s
current
password
v
User’s
new
password
Note
that
the
post
password
change
processing
module
does
not
call
xauthn_authenticate().
User
authentication
is
done
through
the
default
Tivoli
Access
Manager
authentication
mechanism.
The
password
change
occurs
after
authentication
is
complete,
and
the
post
password
change
processing
occurs
after
the
user
has
supplied
a
new
password.
The
post
password
change
processing
module
returns
status
to
the
Web
security
resource
manager.
The
Web
security
resource
manager
audits
the
return
status
but
does
not
take
action
based
on
it.
The
implementer
of
the
authentication
module
must
handle
any
error
conditions
that
arise,
or
that
are
passed
back
to
the
post
password
change
module.
When
a
user’s
password
change
returns
successfully
to
the
default
configured
authentication
mechanism
in
Tivoli
Access
Manager,
then
a
status
of
password
change
success
is
returned
to
the
user.
This
occurs
no
regardless
of
the
return
status
from
the
post
password
change
processing
module.
Chapter
3.
Customizing
authentication
modules
33
UTF-8
compatibility
Custom
authentication
libraries
must
be
compatible
with
UTF-8
encoded
local
code
pages.
This
section
contains
the
following
topics:
v
“UTF-8
compatibility
for
custom
authentication
libraries”
v
“User
credential
data
format”
v
“Entitlements
service
data
format”
v
“Conversion
library
for
authentication
data”
on
page
35
v
“Configuring
the
conversion
library”
on
page
35
Note:
This
section
describes
UTF-8
compatibility
in
WebSEAL.
The
same
compatibility
applies
to
the
Plug-in
for
Web
Servers.
UTF-8
compatibility
for
custom
authentication
libraries
WebSEAL
Version
5.1
and
Plug-in
for
Web
Servers
Version
5.1
have
been
converted
to
use
UTF-8
encoded
strings
when
handling
data
internally.
The
use
of
UTF-8
encoding
enables
WebSEAL
to
provide
multi-locale
support.
This
means
that
WebSEAL
can
support
multiple
languages
at
one
time.
The
use
of
UTF-8
encoded
strings
raises
several
issues
that
can
affect
both
the
implementation
and
use
of
custom
external
authentication
libraries,
such
as
authentication
modules,
that
were
written
to
work
with
prior
versions
of
WebSEAL
and
Tivoli
Access
Manager.
Developers
who
have
deployed
custom
authentication
libraries
for
use
with
prior
versions
of
WebSEAL
should
review
the
issues
in
this
section.
Legacy
custom
authentication
libraries
have
typically
operated
in
single
language
environments
because
each
WebSEAL
process
ran
in
a
single-locale
environment.
These
environments
use
a
local
code
page
that
is
not
UTF-8
enabled.
Since
Tivoli
Access
Manager
and
WebSEAL
processes
now
run
in
a
multi-locale
UTF-8
enabled
environment,
the
format
of
data
read
into
and
written
out
of
these
processes
has
changed.
For
some
custom
authentication
libraries,
this
change
in
data
format
might
require
code
changes
to
the
library.
For
all
custom
authentication
libraries,
a
configuration
(deployment)
change
is
required.
User
credential
data
format
Many
custom
authentication
libraries
access
and
modify
user
credential
information.
This
information
is
obtained
from
Tivoli
Access
Manager
by
using
the
Tivoli
Access
Manager
authorization
C
API.
For
Version
5.1,
the
authorization
C
API
is
now
initialized
to
use
UTF-8
strings.
This
means
that
authorization
libraries
need
to
be
initialized
to
use
UTF-8
as
the
code
page
of
choice.
Calls
to
authorization
API
functionality
need
to
use
UTF-8
arguments,
and
all
code
which
is
invoked
by
authorization
libraries
must
expect
UTF-8
arguments.
This
means
that
customized
authentication
libraries,
such
as
authentication
modules,
that
use
authorization
API
functions
to
process
user
credentials
must
be
modified
to
expect
UTF-8
data.
This
can
affect
switch
user
authentication
modules.
Entitlements
service
data
format
Some
customized
authentication
libraries
also
obtain
data
from
customized
entitlements
services.
The
entitlements
services
must
be
called
with
UTF-8
arguments.
Thus,
legacy
entitlements
services
created
to
work
with
versions
of
Tivoli
Access
Manager
prior
to
version
5.1
might
need
to
be
modified.
34
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Conversion
library
for
authentication
data
To
maintain
backwards
compatibility
with
customized
authentication
libraries
that
expect
data
in
non-UTF-8
format,
WebSEAL
provides
a
conversion
shared
library
for
authentication.
This
shared
library
automatically
converts
data
that
passes
in
and
out
of
authentication
libraries.
WebSEAL
detects
legacy
authentication
modules
that
expect
a
non-UTF-8
local
code
page,
and
converts
outgoing
data
to
those
libraries
into
a
local
code
page
format.
Likewise,
WebSEAL
converts
output
from
the
authentication
libraries
into
UTF-8
format
before
processing
the
data
internally.
Conversion
shared
library
limitations
The
authentication
conversion
shared
library
does
not
support
all
authentication
mechanisms.
The
following
limitation
can
affect
customized
authentication
module
implementations:
v
Switch
user
authentication
module
Customized
switch
user
authentication
module
libraries
must
manipulate
user
credential
data.
The
user
credential
data
is
now
in
UTF-8
format,
as
described
in
the
discussion
above
regarding
authorization
API
initialization
changes.
Customized
switch
user
authentication
module
libraries
must
be
modified
to
handle
credential
data
in
UTF-8
format.
The
following
conversion
shared
library
limitations
do
not
affect
custom
authentication
module
libraries:
v
HTTP
header
authentication
WebSEAL
does
not
interpret
HTTP
Header
data,
so
there
is
no
issue
with
code
page
format.
v
Cross-domain
single
sign-on,
e-community
single
sign-on,
and
failover
authentication
These
authentication
methods
rely
on
user
data
that
is
encoded
in
tokens.
The
tokens
can
be
encoded
either
using
UTF-8
or
not
using
UTF-8.
This
encoding
is
determined
by
settings
in
the
WebSEAL
or
Plug-in
for
Web
Servers
configuration
file.
For
more
information,
see
the
IBM
Tivoli
Access
Manager
for
e-business
WebSEAL
Administration
Guide
or
the
IBM
Tivoli
Access
Manager
for
e-business
Plug-in
for
Web
Servers
Integration
Guide.
v
SSL
is
not
supported
because
this
is
controlled
by
the
GSKit
certificate
handle.
Configuring
the
conversion
library
The
conversion
library
is
called
amwauthconv.
The
actual
library
file
name
is
platform
dependent:
Table
14.
Conversion
shared
library
file
names
Operating
system
Shared
library
name
Solaris
libamwauthnconv.so
AIX
libamwauthnconv.a
Linux
libamwauthnconv.so
HP-UX
libamwauthnconv.sl
Windows
amwauthconv.dll
Chapter
3.
Customizing
authentication
modules
35
Custom
authentication
module
libraries
are
invoked
by
entering
a
command
line
argument
into
the
configuration
file.
For
example,
for
WebSEAL:
cred-ext-attrs
=
/usr/lib/libcustomauth.so&
argument1
argument2
The
conversion
library
is
implemented
as
an
authentication
module
also.
The
conversion
library
takes
one
or
more
arguments.
The
first
argument
is
the
name
of
the
custom
authentication
module
library
that
the
application
uses.
For
example,
if
the
above
sample
library
needs
to
be
used
with
the
conversion
library,
the
entry
in
the
WebSEAL
configuration
file
is
as
follows:
cred-ext-attrs
=
/opt/pdwebrte/lib/libamwauthconv.so&
/usr/lib/libcustomauth.so
argument1
argument2
Note
that
the
above
command
is
entered
as
one
continuous
line.
Note:
If
multiple
conversion
libraries
are
required,
multiple
copies
must
be
used
because
dynamic
loaders
only
load
shared
libraries
once.
36
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Authentication
module
configuration
Tivoli
Access
Manager
supports
many
configuration
options
for
authentication
libraries.
The
following
set
of
instructions
covers
common
cases
as
applicable
to
a
typical
authentication
module
deployment.
The
IBM
Tivoli
Access
Manager
for
e-business
WebSEAL
Administration
Guide
and
the
IBM
Tivoli
Access
Manager
for
e-business
Plug-in
for
Web
Servers
Integration
Guide
contain
detailed
discussions
of
authentication
methods,
libraries,
and
configuration
options.
Before
deploying
your
authentication
module,
you
should
review
the
configuration
material
in
the
Web
security
resource
manager
guide
that
applies
to
the
authentication
method
implemented
by
your
authentication
module.
The
general
sequence
for
configuring
an
authentication
module
can
be
summarized
as
follows:
1.
Stop
the
Web
security
resource
manager,
such
as
WebSEAL.
2.
Open
the
configuration
file
for
editing.
3.
Enter
the
appropriate
authentication
identifier
parameter,
with
the
name
of
the
library,
in
the
[authentication-mechanisms]
stanza.
authentication_method_identifier
=
library_name
The
following
identifiers
specify
built-in
libraries:
Table
15.
Authentication
library
types
specified
in
the
WebSEAL
configuration
file
Identifier
Description
passwd-ldap
Library
that
implements
basic
authentication
with
an
LDAP
user
registry.
cert-ssl
Library
that
implements
certificate
authentication.
token-cdas
Library
that
implements
token
authentication.
http-request
Library
that
implements
HTTP
header
or
IP
address
authentication.
sso-create
Library
that
implements
WebSEAL
single
sign-on
token
creation.
sso-consume
Library
that
implements
WebSEAL
single
sign-on
token
authentication
(consumption).
passwd-cdas
Library
that
implements
an
authentication
module
library
for
either
basic
authentication
or
forms
authentication.
cred-ext-attrs
Library
that
implements
credential
extended
attributes
authentication.
su-password
Library
that
implements
switch
user
authentication
for
basic
authentication
or
forms
authentication.
su-token-card
Library
that
implements
switch
user
authentication
for
token
authentication.
su-certificate
Library
that
implements
switch
user
authentication
for
X.509
certificate
authentication.
su-http-request
Library
that
implements
switch
user
authentication
for
HTTP
header
or
IP
address
authentication.
su-cdsso
Library
that
implements
switch
user
authentication
for
cross-domain
single
sign-on
authentication.
failover-password
Library
that
implements
failover
cookie
authentication
for
basic
authentication
or
forms
authentication.
failover-token-card
Library
that
implements
failover
cookie
authentication
for
token
card
authentication.
Chapter
3.
Customizing
authentication
modules
37
Table
15.
Authentication
library
types
specified
in
the
WebSEAL
configuration
file
(continued)
failover-certificate
Library
that
implements
failover
cookie
authentication
for
certificate
authentication.
failover-http-request
Library
that
implements
failover
cookie
authentication
for
HTTP
header
authentication
or
IP
address
authentication.
failover-cdsso
Library
that
implements
failover
cookie
authentication
for
cross-domain
single
sign-on
authentication.
passwd-strength
Library
that
enforces
custom
password
strength
authentication
policies.
For
example,
if
you
want
to
externalize
LDAP
username/password
authentication
using
a
custom
library
named
libxauthn.so
(for
a
Solaris
system),
enter
the
following
line:
[authentication-mechanisms]
passwd-ldap
=
libxauthn.so
4.
If
the
custom
library
accepts
any
arguments
during
initialization
and
shutdown,
they
can
be
specified
in
the
following
format
(using
the
libxauthn.so
library
as
an
example):
passwd-ldap
=
libxauthn.so&arg1
arg2
....
argN
Note:
When
using
a
custom
library
developed
to
work
with
a
version
of
WebSEAL
or
the
Plug-in
for
Web
Servers
prior
to
Version
5.1,
you
might
need
to
also
call
a
conversion
library.
See
the
instructions
in
“UTF-8
compatibility”
on
page
34.
5.
Copy
the
custom
library
to
the
Web
Security
resource
manager
lib
directory.
For
example,
using
the
sample
library
provided
with
the
ADK
for
Solaris
(libxauthn.so):
WebSEAL:
#
cp
build_dir/libxauthn.so
/opt/pdweb/lib
Plug-in
for
Web
Servers:
#
cp
build_dir/libxauthn.so
/opt/pdwebpi/lib
6.
(Optional)
—
Authentication
module
chaining
allows
a
second
authentication
module
to
be
called
after
the
initial
authentication
module
(built-in
or
custom)
for
the
purpose
of
adding
extended
attribute
data
to
the
Tivoli
Access
Manager
identity.
Typically,
the
Tivoli
Access
Manager
identity
is
obtained
via
a
standard
built-in
authentication
module.
The
secondary
custom
authentication
module
provides
the
additional
extended
attribute
data.
v
Use
the
cred-ext-attrs
parameter
in
the
[authentication-mechanisms]
stanza
of
the
WebSEAL
configuration
file
to
specify
the
custom
library
for
the
secondary
authentication
module.
(Arguments
can
be
specified
as
discussed
in
Step
2
above.)
For
example,
on
Solaris:
cred-ext-attrs
=
libxauthn2.so
Note:
When
using
an
authentication
module
that
was
written
for
a
version
of
WebSEAL
or
Plug-in
for
Web
Servers
prior
to
Version
5.1,
you
should
consider
the
impact
of
the
use
of
UTF-8.
In
some
cases,
this
requires
configuration
of
a
conversion
library.
See
“UTF-8
compatibility”
on
page
34
7.
Ensure
that
each
custom
library
file
has
both
read
and
execute
operating
system
file
permissions
for
the
ivmgr
user.
8.
Restart
the
Web
Security
resource
manager
process.
38
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Chapter
4.
Cross-domain
single
sign-on
authentication
This
chapter
describes
how
to
implement
a
specific
type
of
cross-domain
authentication
service
that
provides
single
sign-on
capabilities
through
token
sharing
across
two
domains.
Topics:
v
“Overview
of
cross-domain
single
sign-on”
on
page
40
v
“Example
libraries”
on
page
44
v
“Implementing
custom
token
create
and
consume
libraries”
on
page
44
v
“Implementing
cross-domain
mapping
framework
libraries”
on
page
48
v
“Configuration
instructions”
on
page
52
©
Copyright
IBM
Corp.
1999,
2003
39
Overview
of
cross-domain
single
sign-on
Tivoli
Access
Manager
Web
security
resource
managers
support
cross-domain
single
sign-on
solutions
for
cross-domain
single
sign-on
(CDSSO)
and
e-community.
Both
cross-domain
single
sign-on
solutions
employ
authentication
tokens
that
describe
or
″vouch
for″
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.″
Note:
For
information
and
configuration
procedures
for
the
default
WebSEAL
CDSSO
functionality,
see
the
IBM
Tivoli
Access
Manager
WebSEAL
Administrator’s
Guide.
For
information
and
configuration
procedures
for
the
default
Plug-in
for
Web
Servers
functionality,
see
the
IBM
Tivoli
Access
Manager
for
e-business
Plug-in
for
Web
Servers
Integration
Guide.
You
can
write
custom
library
files
that
can
create
and
consume
tokens
used
in
cross-domain
and
cross-server
single
sign-on
solutions.
The
default
Tivoli
Access
Manager
CDSSO
functionality
allows
users
to
seamlessly
log
on
to
other
WebSEAL,
Plug-in
for
Web
Server,
or
non-Tivoli
Access
Manager
servers.
The
initial
and
destination
servers
can
be
located
in
the
same
secure
domain,
or
in
different
domains
(cross-domain).
CDSSO
is
primarily
designed
to
provide
a
single
sign-on
solution
between
two
servers
located
in
different
domains.
CDSSO
functions
when
a
user
makes
a
request
to
a
remote
resource
by
clicking
on
a
specially
constructed
link
located
on
a
page
belonging
to
the
initial
Web
security
resource
manager.
The
user
must
have
a
valid
account
with
the
initial
Tivoli
Access
Manager
Web
security
resource
manager
and
must
have
successfully
logged
in.
The
link
refers
to
a
special
CDSSO
management
page
called
pkmscdsso.
The
CDSSO
mechanism
(triggered
by
this
link)
creates
and
encodes
a
special
CDSSO
authentication
token
containing
the
user’s
existing
credential
information,
plus
any
extended
credential
attributes
that
further
identify
the
user.
The
user
identity,
required
by
the
destination
server,
is
defined
by
the
information
in
this
token.
The
token
is
sent
off
as
a
query
string
argument
in
a
specially
formatted
redirect
to
the
destination
server
where
the
resource
is
located.
The
destination
server
recognizes
the
special
format
of
the
incoming
request
as
a
CDSSO
request
containing
authentication
information.
The
token
is
decoded
and
the
server
now
has
the
user’s
identity,
as
authenticated
on
the
first
sever.
If
the
user
has
an
equivalent
account
with
this
server,
the
server
logs
the
user
on.
Otherwise,
further
identity
mapping
may
be
required.
If
the
destination
server
is
a
WebSEAL
server
or
server
with
the
Plug-in
for
Web
Server,
the
cross-domain
mapping
framework
can
be
called
to
perform
this
mapping
requirement.
Successful
authentication,
with
valid
authorization
checks,
results
in
the
requested
resource
being
served
to
the
user.
Throughout
this
exchange,
the
user
was
not
forced
to
perform
a
second
login.
The
next
two
sections
explain
how
token
creation
and
consumption
occurs
for
the
default
CDSSO
functionality
between
two
WebSEAL
servers.
The
same
concepts
apply
to
the
Plug-in
for
Web
Servers.
40
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Default
token
creation
CDSSO
token
creation
occurs
when
an
authenticated
user
on
webseal1
requests
a
resource
from
webseal2
through
a
special
link
located
on
webseal1.
The
link
refers
to
a
special
CDSSO
management
page
called
pkmscdsso
that
calls
the
CDSSO
built-in
token
create
library
(ssocreate).
The
link
also
contains
the
destination
URL
where
the
resource
is
located.
The
following
example
illustrates
a
CDSSO
link
to
a
remote
resource:
http://webseal1.ibm.com/pkmscdsso?http://webseal2/resource.html
Once
this
link
is
activated,
the
token
create
library
encodes
the
authenticated
user’s
existing
credential
information
and
includes
the
information
as
a
query
string
argument
in
a
redirected
request
to
the
resource
on
webseal2,
using
the
destination
URL
supplied
in
the
link.
The
cdsso-argument
parameter
in
the
[cdsso]
stanza
of
the
WebSEAL
configuration
file
tells
the
default
token
create
library
what
name
to
use
as
a
label
for
the
encoded
token
information
in
the
query
string
argument
(default
=
PD-ID).
It
is
this
unique
label
that
triggers
the
token
consume
library
on
webseal2.
The
following
example
illustrates
the
format
of
a
CDSSO
redirected
request:
http://webseal2/resource.html?PD-ID=encoded_authentication_token
You
can
create
your
own
custom
token
create
library
that
formats
and
encodes
the
arguments
included
in
the
redirected
request.
The
custom
library
can
alter
the
format
and
content
of
the
redirected
request
to
accommodate
the
consumption
requirements
of
another
WebSEAL
server
or
a
non-WebSEAL
server.
For
example,
if
you
are
using
a
WebSEAL
server,
a
call
to
a
cross-domain
mapping
framework
can
be
coded
to
supply
extended
attributes
that
further
define
the
user’s
identity.
Creating
a
custom
token
create
library
in
explained
in
Chapter
4,
“Cross-domain
single
sign-on
authentication,”
on
page
39.
Note:
For
information
on
CDSSO
in
the
Plug-in
for
Web
Servers
component,
see
IBM
Tivoli
Access
Manager
for
e-business
Plug-in
for
Web
Servers
Integration
Guide.
Default
token
consumption
The
webseal2
server
receives
the
redirected
request
and
recognizes
the
request
as
a
CDSSO
request
because
of
the
″PD-ID″
token
argument
label.
The
″PD-ID″
label
is
also
defined
for
webseal2
by
the
cdsso-argument
parameter
in
the
[cdsso]
stanza
of
the
WebSEAL
configuration
file.
The
″PD-ID″
label
in
the
request
triggers
a
call
to
the
built-in
token
consume
library
(ssoconsume).
The
library
decodes
the
query
string
containing
the
token
and
reveals
the
user’s
identity
information.
The
webseal2
server
can
use
this
information
to
authenticate
the
user
and
perform
authorization
on
the
resource
request.
You
can
create
your
own
token
consume
library
that
handles
the
incoming
query
string
information.
The
custom
library
can
be
written
to
correctly
decode
a
token
created
from
the
custom
requirements
of
another
WebSEAL
server
or
a
non-WebSEAL
server.
For
example,
if
you
are
using
a
WebSEAL
server,
a
call
to
a
CDMF
can
be
coded
to
map
the
token
authentication
information
to
an
identity
known
to
this
destination
server.
Creating
a
custom
token
consume
library
in
explained
in
Chapter
4,
“Cross-domain
single
sign-on
authentication,”
on
page
39.
Chapter
4.
Cross-domain
single
sign-on
authentication
41
Note:
For
information
on
CDSSO
in
the
Plug-in
for
Web
Servers
component,
see
IBM
Tivoli
Access
Manager
for
e-business
Plug-in
for
Web
Servers
Integration
Guide.
Mapping
user
identities
The
cross-domain
mapping
framework
(CDMF)
is
a
programming
interface
you
can
use
to
build
a
custom
library
that
provides
mapping
services
for
a
user
identity
and
handles
any
extended
user
attributes.
The
CDMF
is
an
important
component
used
with
Tivoli
Access
Manager
cross
domain
single
sign-on
solutions:
v
“Identity
mapping
across
domains”
(CDSSO)
v
“Identity
mapping
in
an
e-community
environment”(ECSSO)
Identity
mapping
across
domains
The
Tivoli
Access
Manager
cross-domain
single
sign-on
(CDSSO)
provides
a
mechanism
for
transferring
user
credentials
across
multiple
secure
domains.
CDSSO
allows
Web
users
to
perform
a
single
sign-on
and
move
seamlessly
between
two
separate
secure
domains.
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
sign-on.
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
second
domain
now
has
the
user’s
identity
(as
authenticated
in
the
first
domain)
and
the
user
is
not
forced
to
perform
another
login.
In
many
CDSSO
scenarios,
the
default
one-to-one
mapping
between
users
from
different
domains
may
not
suit
all
deployment
requirements.
The
CDMF
allows
the
mapping
of
a
remote
user
to
a
local
user
identity.
Identity
mapping
in
an
e-community
environment
E-community
single
sign-on
is
another
implementation
of
cross-domain
authentication
in
a
Tivoli
Access
Manager
environment.
The
goal
of
cross-domain
authentication
is
to
allow
users
to
access
resources
across
multiple
servers
in
multiple
domains
without
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
disparate
businesses
with
a
shared
relationship.
For
example,
company
headquarters,
a
life
insurance
company,
and
a
financial
management
company.
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.
42
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Individual
e-community
domains
manage
their
own
user
identities
and
associated
privileges.
You
can
use
the
CDMF
to
map
a
user
from
a
remote
domain
to
a
valid
user
in
the
local
domain.
If
the
e-community
domains
share
global
identities,
this
mapping
function
is
not
required.
For
e-community
background,
administration,
and
configuration
information,
refer
to
either
the
IBM
Tivoli
Access
Manager
for
e-business
WebSEAL
Administration
Guide
or
the
IBM
Tivoli
Access
Manager
for
e-business
Plug-in
for
Web
Servers
Integration
Guide.
Chapter
4.
Cross-domain
single
sign-on
authentication
43
Implementing
custom
token
create
and
consume
libraries
You
can
create
a
custom
CDSSO
token
create/consume
library
by
modifying
the
example
xauthn.c
source
file
included
with
the
Web
Security
external
authentication
ADK.
The
xauthn.c
source
file
is
located
in
the
example
sub-directory
of
the
ADK
(pdxauthn_adk).
Example
libraries
Token
create
and
token
consume
functionality
can
be
contained
in
one
library,
or
separated
into
two
individual
libraries.
WebSEAL
and
the
Plug-in
for
Web
Servers
uses
two
distinct
built-in
libraries
to
handle
the
token
creation
and
token
consumption
tasks
of
the
default
CDSSO
functionality:
Table
16.
Token
creation
and
consumption
libraries
Operating
system
File
names
Solaris,
Linux
libssocreate.so
libssoconsume.so
AIX
libssocreate.a
libssoconsume.a
Windows
ssocreate.dll
ssoconsume.dll
HP-UX
libssocreate.sl
libssoconsume.sl
The
Web
Security
ADK
provides
a
pre-built
platform-specific
example
library
that
demonstrates
CDSSO
functionality
similar
to
the
functionality
provided
by
the
built-in
default
libraries.
The
example
library
performs
both
token
creation
and
token
consumption
tasks
and
was
built
from
the
xauthn.c
source
file.
You
use
the
xauthn.c
source
file
as
the
starting
point
for
building
your
own
custom
library.
In
addition,
the
example
library
provides
output
data
during
the
token
creation
and
consumption
processing
when
you
use
the
library
in
a
test
environment.
This
output
is
sent
by
default
to
the
Web
server
log
file.
For
WebSEAL
the
log
file
is
msg_webseald.log.
The
output
can
be
useful
for
analyzing
the
proper
functionality
of
the
library.
The
example
library
file
is
located
in
the
example
sub-directory
of
the
Web
Security
external
authentication
ADK
(pdxauthn_adk)
and
has
the
following
platform-specific
file
name:
Table
17.
Example
CDSSO
library
file
name
Operating
system
Filename
Solaris,
Linux
libxauthn.so
AIX
libxauthn.a
Windows
xauthn.dll
HP-UX
libxauthn.sl
Since
both
the
create
and
consume
functionality
are
contained
within
the
same
library
file,
you
must
specify
the
full
path
name
to
this
library
for
both
the
sso-create
and
sso-consume
parameters
in
the
[authentication-mechanisms]
stanza
of
the
Web
server
configuration
file.
For
example,
on
Solaris:
44
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
[authentication-mechanisms]
sso-create
=
/opt/pdwebrte/pdxauthn_adk/example/libxauthn.so
sso-consume
=
/opt/pdwebrte/pdxauthn_adk/example/libxauthn.so
You
can
use
the
following
default
directory
to
store
your
custom
libraries:
WebSEAL:
UNIX:
/opt/pdwebrte/lib/
Windows:
C:\Program
Files\Tivoli\PDWebRTE\bin\
Similarly,
you
must
specify
the
full
path
name
to
the
custom
library
in
the
Web
server
configuration
file.
For
example,
on
Solaris:
[authentication-mechanisms]
sso-create
=
/opt/pdwebrte/lib/custom-library.so
sso-consume
=
/opt/pdwebrte/lib/custom-library.so
Creating
and
building
a
custom
token
create/consume
library
You
create
a
custom
token
create/consume
library
by
first
customizing
the
xauthn.c
source
file
located
in
the
example
sub-directory
of
the
Web
Security
external
authentication
ADK
(pdxauthn_adk).
Information
contained
in
the
remainder
of
this
chapter
and
in
the
xauthn.c
source
file
itself
provides
further
detail
on
how
to
create
your
custom
library.
You
can
give
the
custom
library
any
file
name.
The
file
name
is
defined
when
you
compile
and
build
the
library.
Information
contained
in
the
Makefile
template
provides
platform-specific
instructions
on
compiling
and
building
the
library
from
the
source
file.
Customizing
the
token
create
library
interface
The
Web
security
resource
manager
(WebSEAL
or
the
Plug-in
for
Web
Servers)
passes
client
authentication
information
to
the
custom
token
create
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().
For
more
information
on
retrieving
values
from
xnvlist_t,
see
the
reference
page
for
xnvlist_get().
The
token
create
functionality
typically
generates
a
redirected
request
containing
the
destination
URL
of
the
resource
and
the
encoded
credential
of
the
user.
A
custom
token
create
library
must
generate
a
customized
version
of
this
redirect.
The
following
valid
user
authentication
data
from
the
Web
security
resource
manager,
provided
as
an
xnvlist_t
data
structure,
is
passed
to
the
token
creation
interface:
Table
18.
Identifiers
used
for
single
sign-on
create
authentication
Name
Description
XAUTHN_BROWSER_INFO
Browser
information
Example:"Mozilla/4.0
(Compatible;
MSIE
6.0;
Windows
NT
5.0)"
Chapter
4.
Cross-domain
single
sign-on
authentication
45
Table
18.
Identifiers
used
for
single
sign-on
create
authentication
(continued)
XAUTHN_EXISTING_CRED
Used
only
for
reauthentication.
This
contains
the
user’s
existing
credential
as
a
string.
Example:
″0123456″
XAUTHN_IPADDR
User
IP
address.
For
example:
11.22.33.44
XAUTHN_QOP
Quality
of
protection.
The
format
is
authentication_method:version:cipher_used
The
quality
of
protection
for
Plug-in
for
Web
Servers
is
always
none.
XAUTHN_SSO_TYPE
This
is
a
string
that
is
created
and
freed
by
WebSEAL.
This
is
passed
down
to
the
calling
library
to
inform
it
whether
it
was
called
to
use
the
create
function
or
the
consume
function.
This
is
important
when
both
token
creation
and
token
consumption
are
written
into
the
same
library.
Values
can
be
xauthn.sso.create
or
xauthn.sso.consume.
XAUTHN_INPUT_URL
Destination
URL.
For
example:
http://foo.com/request.htm
The
xauthn_sso_type
is
set
to
SSO_CREATE.
The
xauthn_input_url
is
set
to
the
destination
URL
where
the
resource
is
located.
For
example:
http://webseal2.ibm.com/resource.html
For
descriptions
of
the
other
authentication
data
types,
see
“Obtain
user
authentication
information”
on
page
24.
Normally
a
custom
library
using
the
xauthn
interface
(for
token
create/consume
functionality)
is
required
to
return
a
client
identity
back
to
the
Web
security
resource
manager
using
the
xauthn_identity_t
identity
structure.
However,
the
actual
requirement
of
a
token
create
library
is
to
return
a
redirected
request
string
(URL).
This
string
can
be
passed
back
to
WebSEAL
by
storing
the
redirect
URL
string
in
the
xattr_list_t
data
structure
of
the
identity
structure.
The
information
provided
to
xattr_list_t
can
be
set
using
the
xattr_set()
utility.
You
must
set
the
value
of
this
URL
string
using
the
name
cdsso-redirect-url.
The
identity
structure
is
then
passed
to
WebSEAL
and
the
request
is
redirected
using
the
URL
string
provided
as
cdsso-redirect-url.
Output
Name
Description
cdsso-redirect-url
Redirected
request
URL
string
with
encoded
authentication
data.
The
value
for
cdsso-redirect-url
appears
similar
to
the
following
example:
http://webseal2.ibm.com/resource.html?TOKEN=encoded_authentication_data
The
above
redirect
URL
string
is
constructed
using
the
destination
URL
from
the
link
activated
on
the
original
server,
plus
the
user
credential
information
passed
in
from
the
xauthn_existing_cred
authentication
identifier
created
for
the
46
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
authenticated
user
by
the
original
Web
security
resource
manager.
In
addition,
the
custom
token
create
library
can
call
out
to
include
extended
attributes
that
further
define
the
user’s
identity.
Customizing
the
token
consume
library
interface
The
label
identifying
the
encoded
token
argument
string
(configured
in
the
cdsso-argument
parameter
in
the
configuration
file)
allows
the
receiving
server
to
recognize
the
incoming
request
as
a
redirected
CDSSO
request
and
to
invoke
the
token
consume
library.
The
token
consume
library
decodes
the
token
information
and
passes
down
the
following
valid
user
authentication
data,
provided
as
an
xnvlist_t
data
structure:
Table
19.
Identifiers
used
for
single
sign-on
consume
library
Name
Description
XAUTHN_BROWSER_INFO
Browser
information
Example:"Mozilla/4.0
(Compatible;
MSIE
6.0;
Windows
NT
5.0)"
XAUTHN_EXISTING_CRED
Used
only
for
reauthentication.
This
contains
the
user’s
existing
credential
as
a
string.
Example:
″0123456″
XAUTHN_IPADDR
User
IP
address.
For
example:
11.22.33.44
XAUTHN_QOP
Quality
of
protection.
The
format
is
authentication_method:version:cipher_used
The
quality
of
protection
for
Plug-in
for
Web
Servers
is
always
none.
XAUTHN_SSO_TYPE
This
is
a
string
that
is
created
and
freed
by
WebSEAL.
This
is
passed
down
to
the
calling
library
to
inform
it
whether
it
was
called
to
use
the
create
function
or
the
consume
function.
This
is
important
when
both
token
creation
and
token
consumption
are
written
into
the
same
library.
Values
can
be
xauthn.sso.create
or
xauthn.sso.consume.
XAUTHN_QUERY_STRING
Query
string
of
the
redirected
request.
The
xauthn_sso_type
is
set
to
SSO_CONSUME.
The
xauthn_query_string
is
set
to
the
query
string
of
the
redirected
request
containing
encoded
authentication
data
and,
optionally,
additional
attributes.
For
example:
?TOKEN=encoded_data
The
token
consume
library
returns
a
client
identity
back
to
the
secure
Web
using
the
xauthn_identity_t
identity
structure.
The
Web
security
resource
manager
can
use
this
identity
information
to
authenticate
the
user
and
continue
processing
the
request.
Chapter
4.
Cross-domain
single
sign-on
authentication
47
Implementing
cross-domain
mapping
framework
libraries
The
specific
operation
of
a
customized
cross-domain
mapping
framework
(CDMF)
library
is
determined
by
the
developer.
Use
the
CDMF
API
functions
and
utilities
to
implement
the
required
cross
domain
identity
mapping
and
extended
user
attribute
handling.
Two
CDMF
libraries
always
work
as
partners.
One
CDMF
library—associated
with
the
local
WebSEAL
(or
Plug-in
for
Web
Servers)
CDSSO
server
or
the
″vouch
for″
server
(e-community)—supplies
extended
attributes
in
the
authentication
token
(CDSSO)
or
″vouch
for″
reply
token
(e-community).
The
second
CDMF
library,
which
is
written
as
a
partner
to
the
first,
performs
the
following
operations:
v
Expects
possible
extended
attributes.
v
Maps
the
remote
user
identity
to
a
local
user
identity.
The
second
CDMF
library
is
associated
with
the
WebSEAL
server
or
Plug-in
for
Web
Servers
server
in
the
remote
domain
that
is
the
target
of
the
request.
The
custom
CDMF
library
must
contain
two
application
programming
interfaces.
The
first
interface,
called
by
the
local
WebSEAL
CDSSO
server
(or
Plug-in
for
Web
Servers
server)
or
the
″vouch
for″
server
(e-community),
serves
the
request
by
providing
extended
user
attribute
information.
The
second
interface
is
called
by
the
WebSEAL
or
Plug-in
for
Web
Servers
server
in
the
remote
domain
(CDSSO)
or
the
target
WebSEAL
(or
Plug-in
for
Web
Servers)
server
(e-community)
and
provides
user
identity
mapping
services
for
the
request.
This
section
contains
the
following
topics:
v
“Software
requirements”
v
“Build
instructions”
v
“Customizing
the
example
source
file”
on
page
49
v
“Cross-domain
mapping
framework
functions”
on
page
49
v
“Providing
user
attributes:
cdmf_get_usr_attributes()”
on
page
50
v
“Providing
identity
mapping:
cdmf_map_usr()”
on
page
50
Software
requirements
There
are
no
software
dependencies
when
building
the
CDMF
library.
To
use
a
CDMF
library,
you
must
have
at
least
two
Tivoli
Access
Manager
secure
domains
installed,
each
containing
a
WebSEAL
or
Plug-in
for
Web
Servers
server.
Build
instructions
Windows-specific
macros
The
following
two
macros
are
required
when
building
the
shared
library
on
a
Windows
platform.
The
macros
should
not
be
redefined
or
changed.
v
CDMF_DECLSPEC()
v
CDMF_CALLTYPE()
48
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Customizing
the
example
source
file
1.
Edit
the
cdmf.c.skelton
source
file
and
modify
the
cdmf_map_usr
and
cdmf_get_usr_attributes
functions
to
enable
the
required
user
mapping
and
user
attribute
handling.
2.
Rename
the
modified
cdmf.c.skeleton
file
to
cdmf.c.
3.
For
UNIX
platforms,
edit
Makefile.cdmf.in
and
make
any
modifications
required
to
build
the
library
for
the
appropriate
development
platform.
Instructions
appear
in
the
comments
at
the
top
of
the
file.
For
Windows
platforms,
Makefile.win32
requires
no
modification.
4.
Build
the
custom
CDMF
library.
Provide
the
following
platform-specific
name
for
the
library
file:
Table
20.
CDMF
library
file
name
Operating
system
File
name
Solaris,
Linux
libcdmf.so
AIX
libcdmf.a
HP-UX
libcdmf.sl
Windows
cdmf.dll
Note:
If
you
build
the
CDMF
library
on
a
Solaris
system
using
C++
and
Sun
Workshop
5
or
greater,
the
library
must
be
built
with
the
″–compat=4″
flag.
5.
Stop
the
server
process
(webseald
or
pdwebpi).
6.
Replace
the
original
CDMF
library
that
was
shipped
with
the
Tivoli
Access
Manager
product
with
the
customized
version.
7.
Start
webseald
or
pdwebpi.
Cross-domain
mapping
framework
functions
The
CDMF
API
functions
are
located
in
one
directory.
Cross-domain
mapping
framework
API
functions
You
implement
the
following
API
functions
in
your
custom
authentication
module:
v
cdmf_map_usr()
v
cdmf_get_usr_attributes()
Utility
functions
The
following
utility
functions
manipulate
data
for
extended
user
attributes:
v
cdmf_create_usr_attr_list()
v
cdmf_create_usr_attr()
v
cdmf_add_value_to_attr()
v
cdmf_add_attr_to_list()
Memory
management
macros
The
following
memory
management
macros
should
be
used
so
WebSEAL
can
safely
handle
any
allocated
memory:
v
CDSSO_FREE()
Chapter
4.
Cross-domain
single
sign-on
authentication
49
v
CDSSO_MALLOC()
v
CDSSO_REALLOC()
v
CDSSO_STRDUP()
Providing
user
attributes:
cdmf_get_usr_attributes()
The
cdmf_get_usr_attributes()
interface
allows
extended
user
attributes
to
be
passed
in
the
authentication
token
(CDSSO)
or
the
″vouch
for″
reply
token
(e-community)
and
is
called
by
the
WebSEAL
or
Plug-in
for
Web
Servers
server
in
the
following
situations:
v
When
a
CDSSO
request
is
initiated
by
a
user
accessing
the
/pkmscdsso
page
on
the
local
WebSEAL
or
Plug-in
for
Web
Servers
server.
v
When
an
e-community
″vouch
for″
server
generates
a
″vouch
for″
reply
token
for
another
WebSEAL
or
Plug-in
for
Web
Servers
server
in
the
e-community.
The
input
parameter
to
this
function
is
the
short
name
of
the
user
on
the
local
WebSEAL
or
Plug-in
for
Web
Servers
server
(CDSSO)
or
the
″vouch
for″
server
(e-community).
The
output
parameter
is
the
attribute
list
constructed
by
the
CDMF
utility
functions.
In
a
CDSSO
scenario,
the
attribute
list
is
included
in
the
authentication
token
that
is
constructed
and
sent
to
the
remote
WebSEAL
or
Plug-in
for
Web
Servers
server
that
is
the
target
of
the
request.
In
an
e-community
scenario,
this
attribute
list
is
included
in
the
″vouch
for″
reply
token
sent
to
the
remote
WebSEAL
or
Plug-in
for
Web
Servers
server
that
is
the
target
of
the
request.
The
CDMF
library
at
the
remote
WebSEAL
or
Plug-in
for
Web
Servers
server
can
use
the
information
contained
in
this
attribute
list
when
producing
a
user
identity.
Providing
identity
mapping:
cdmf_map_usr()
The
cdmf_map_usr()
interface
is
called
by
WebSEAL
or
Plug-in
for
Web
Servers
to
perform
the
mapping
from
the
remote
user
to
a
local
user
identity
and
is
required
in
the
following
situations:
v
When
a
URL
containing
a
CDSSO
authentication
token
is
received
by
WebSEAL
or
by
a
Plug-in
for
Web
Servers
server.
When
a
CDSSO
request
originating
in
domain
A
is
received
by
the
domain
B
WebSEAL
or
Plug-in
for
Web
Servers
server,
the
identity
of
the
local
user
must
be
determined.
The
cdmf_map_usr()
interface
is
called
to
map
the
remote
user
(who
initiated
the
CDSSO
request)
to
a
local
user
identity.
v
When
a
URL
containing
an
e-community
″vouch
for″
token
is
received
by
WebSEAL
or
by
a
Plug-in
for
Web
Servers
server.
When
a
″vouch
for″
reply
token
is
received
by
a
WebSEAL
or
Plug-in
for
Web
Servers
server
(which
is
the
target
of
the
request)
from
a
″vouch
for″
server,
that
WebSEAL
or
Plug-in
for
Web
Servers
server
may
be
required
to
map
the
identity
of
the
requesting
user
to
a
local
user
identity.
The
input
parameter
to
this
function
is
the
cdsso_usr_info_t
data
type,
which
contains
the
user
name,
domain,
and
an
attribute
list.
This
input
information
is
used
by
the
custom
CDMF
library
to
determine
a
local
user
identity.
Any
50
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
information
contained
in
the
attribute
list
was
added
by
the
cdmf_get_usr_attributes
function
call
to
the
first
CDMF
library.
The
output
information
is
also
contained
in
a
cdsso_usr_info_t
data
type.
The
only
required
field
is
the
user
name,
which
is
the
short
name
of
the
local
(or
requesting)
user.
The
local
user’s
attribute
list
is
an
optional
field
that
can
be
filled
out
if
the
user’s
credential
requires
extended
attributes.
Because
the
credential’s
extended
attribute
list
only
supports
one
value,
only
the
first
value
for
each
attribute
will
become
part
of
the
user’s
credential.
The
domain
field
is
ignored.
v
If
the
final
user
mapping
is
successful,
CDMF_SUCCESS
should
be
returned.
v
If
no
identity
mapping
occurs,
CDMF_NOMAP
should
be
returned.
v
If
an
error
occurs,
CDMF_FAILURE
should
be
returned.
v
If
CDMF_SUCCESS
is
not
returned,
no
memory
clean
up
is
performed
on
the
local
user
information.
Specifying
extended
attributes
Both
CDMF
application
programming
interfaces
support
additional
user
information
in
the
form
of
a
CDSSO
attribute
list.
Although
this
type
is
called
a
CDSSO
attribute
list,
this
list
can
be
used
by
the
CDMF
functions
to
communicate
user
information
in
both
CDSSO
and
e-community
scenarios.
The
CDSSO
attribute
list
cdsso_attrlist_t
is
a
name/multiple
value
data
list
that
is
defined
in
cdssotypes.h.
The
utility
functions
that
are
required
to
construct
this
list
are
defined
in
the
file
cdmf_utils.h.
These
utility
functions
perform
the
following
operations:
v
Create
a
CDSSO
user
attribute
list
v
Create
a
CDSSO
user
attribute
v
Add
a
value
to
a
CDSSO
user
attribute
v
Add
a
CDSSO
user
attribute
to
the
user
attribute
list
For
detailed
information,
consult
the
following
reference
pages:
v
cdmf_create_usr_attr_list()
v
cdmf_create_usr_attr()
v
cdmf_add_value_to_attr()
v
cdmf_add_attr_to_list()
Chapter
4.
Cross-domain
single
sign-on
authentication
51
Configuration
instructions
Sending
single
sign-on
requests
to
a
non-WebSEAL
server
CDSSO
is
a
functionality
that
provides
a
single
sign-on
solution
between
two
Tivoli
Access
Manager
Web
security
resource
managers.
This
section
describes
how
to
set
up
a
Tivoli
Access
Manager
Web
security
resource
manager
to
send
a
single
sign-on
request
to
an
external
(non-Tivoli
Access
Manager
protected)
destination
server.
1.
Create
a
custom
token
create
library
based
on
the
example
xauthn.c
source
file.
This
code
must
be
written
to
generate
redirected
requests
in
a
format
acceptable
by
the
non-Tivoli
Access
Manager
protected
destination
server.
2.
In
the
server
configuration
file,
set
the
sso-create
authentication
mechanism
parameter
to
the
full
path
name
of
the
token
create
library
file.
For
example,
on
Solaris:
[authentication-mechanisms]
sso-create
=
/opt/pdwebrte/lib/libxauthn.so
You
must
specify
a
full
path
name
to
this
the
library.
3.
Enable
the
Web
security
resource
manager
to
process
single
sign-on
requests
by
communication
type:
WebSEAL:
[cdsso]
cdsso-create
=
{http
|
https
|
both}
Plug-in
for
Web
Servers:
[common-modules]
pre-authzn
=
cdsso
4.
Create
a
special
link
on
the
appropriate
page
of
this
server
that
requests
the
single
sign-on
to
the
non-Tivoli
Access
Manager
protected
server
and
activates
the
token
create
library.
For
example,
for
WebSEAL:
http://webseal.ibm.com/pkmscdsso?https://non-webseal.example.com/resource.html
If
the
customized
library
fails
for
some
reason,
an
xnvlist
attribute
should
be
allocated
with
the
specified
return
value
name
(see
the
example
code),
but
with
a
null
value.
For
example,
WebSEAL
can
then
serve
a
WebSEAL
″Not
Found″
error
page
to
the
browser.
When
the
CDSSO
link
is
activated
by
an
authenticated
user,
the
token
create
library
constructs
a
redirect
request
made
up
of
the
destination
URL
and
encoded
identity
information
describing
the
user.
The
format
and
contents
of
the
redirected
request
URL,
constructed
by
the
custom
library,
must
be
compatible
with
how
the
non-WebSEAL
(or
non-Plug-in
for
Web
Servers)
destination
server
is
configured
to
accept
and
read
this
request.
Accepting
single
sign-on
requests
from
a
non-WebSEAL
server
This
section
describes
how
to
set
up
a
Tivoli
Access
Manager
Web
security
resource
manager
(either
a
WebSEAL
server
or
a
Plug-in
for
Web
Servers
server)
to
accept
a
single
sign-on
request
from
a
server
that
is
not
protected
by
Tivoli
Access
Manager
security.
1.
Create
a
custom
token
consume
library
based
on
the
example
xauthn.c
source
file.
52
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
This
code
must
be
written
to
successfully
parse
and
decode
requests
in
a
format
created
by
the
server
that
is
not
protected
by
Tivoli
Access
Manager
security.
2.
In
the
Tivoli
Access
Manager
Web
server
configuration
file,
set
the
sso-consume
authentication
mechanism
parameter
to
the
full
path
name
of
the
token
create
library
file.
For
example,
on
Solaris:
[authentication-mechanisms]
sso-consume
=
/opt/pdwebrte/lib/libxauthn.so
You
must
specify
a
full
path
name
to
this
the
library.
3.
Enable
the
Web
security
resource
manager
to
process
single
sign-on
requests
by
communication
type:
WebSEAL:
[cdsso]
cdsso-auth
=
{http
|
https
|
both}
Plug-in
for
Web
Servers
[common-modules]
authentication
=
cdsso
4.
Set
the
cdsso-argument
label
to
the
appropriate
value
that
matches
what
the
server
that
is
not
protected
by
Tivoli
Access
Manager
sends
in
its
request
and
that
uniquely
identifies
the
request
as
a
single
sign-on
request
to
be
handled
by
the
Tivoli
Access
Manager
Web
security
resource
manager’s
CDSSO
functionality:
[cdsso]
cdsso-argument
=
token_argument_ID
The
Web
security
resource
manager
receives
the
redirected
request
URL
from
the
non-secured
server.
The
token_argument_ID
label
informs
the
Web
security
resource
manager
that
this
is
a
CDSSO
request.
The
token
consume
library
is
activated.
The
library
parses
and
decodes
the
query
string
of
the
request.
The
resulting
user
identity
is
passed
to
the
Web
security
resource
manager
which
uses
it
to
authenticate
the
user
and
continue
processing
the
resource
request.
The
custom
library
must
be
written
to
understand
the
format
and
contents
of
the
query
string
constructed
by
the
server
that
is
external
to
the
Tivoli
Access
Manager
Web
security
resource
manager.
If
authentication
is
not
successful,
the
Tivoli
Access
Manager
Web
security
resource
manager
presents
the
user
with
a
login
prompt.
Chapter
4.
Cross-domain
single
sign-on
authentication
53
54
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Appendix
A.
External
authentication
C
API
reference
v
“xnvlist_get()”
on
page
56
v
“xattr_get()”
on
page
57
v
“xattr_set()”
on
page
58
v
“xauthn_authenticate()”
on
page
59
v
“xauthn_change_password()”
on
page
60
v
“xauthn_initialize()”
on
page
61
v
“xauthn_shutdown()”
on
page
62
v
“xauthn_util_entry_to_creds()”
on
page
63
©
Copyright
IBM
Corp.
1999,
2003
55
xnvlist_get()
Retrieves
the
value
and
length
of
a
given
name
in
the
name/value
list.
Syntax
int
xnvlist_get(
xnvlist_t
*list,
char
*name,
char
**value,
int
*vlen
);
Description
Retrieves
the
value
and
length
of
a
given
name
in
the
name/value
list.
Parameters
Input
list
A
pointer
to
the
name/value
list.
name
A
pointer
to
a
name
whose
value
is
to
be
retrieved.
Output
value
A
pointer
to
a
pointer
that
stores
the
value
of
a
given
name.
The
caller
of
this
function
should
free
the
memory
for
the
**value
when
finished.
vlen
A
pointer
to
a
pointer
that
stores
the
length
of
the
returned
value.
Return
Values
This
function
returns
0
upon
success.
Otherwise,
it
returns
1.
56
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
xattr_get()
Retrieves
the
value
of
a
given
name
in
the
extended
attribute
list.
Syntax
int
xattr_get(
xattr_list_t
*list,
char
*name,
char
**value
);
Description
Retrieves
the
value
of
a
given
name
in
the
extended
attribute
list.
Parameters
Input
list
A
pointer
to
the
name/value
list.
name
A
pointer
to
a
name
of
the
attribute
to
retrieve.
Output
value
A
pointer
to
a
pointer
that
stores
the
value
of
a
given
name.
The
caller
of
this
function
should
not
free
the
value
returned.
Return
Values
This
function
returns
0
upon
success.
Otherwise,
it
returns
1.
Appendix
A.
External
authentication
C
API
reference
57
xattr_set()
Stores
a
name
and
a
value
into
the
extended
attribute
list.
Syntax
int
xattr_set(
xattr_list_t
*list,
char
*name,
char
*value
);
Description
Stores
a
name
and
a
value
into
the
extended
attribute
list.
The
caller
does
not
need
to
free
name
or
value.
These
will
be
freed
when
the
attribute
list
is
freed.
Parameters
Input
list
A
pointer
to
the
name/value
list.
name
A
pointer
to
a
name.
The
name
should
be
dynamically
allocated
using
malloc().
value
A
pointer
to
a
value
of
the
given
name.
The
value
should
be
dynamically
allocated
using
malloc().
Return
Values
This
function
returns
0
upon
success.
Otherwise,
it
returns
1.
58
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
xauthn_authenticate()
Performs
the
authentication
module
authentication
tasks.
Syntax
xauthn_status_t
xauthn_authenticate(
xnvlist_t
*authnInfo,
xauthn_identity_t
*ident
);
Description
The
authentication
dispatcher
calls
this
interface
to
perform
the
customer-specific
external
authentication.
Client
authentication
information
is
passed
by
the
dispatcher
through
the
input
argument
authnInfo.
Refer
to
“Obtain
user
authentication
information”
on
page
24
for
the
list
of
authentication
data
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
WebSEAL.
It
is
important
to
note
that
the
client
identity
ident
can
contain
additional
user
information.
WebSEAL
frees
ident.
The
implementer
of
this
function
should
not
free
ident.
Parameters
Input
authnInfo
The
authnInfo
parameter
is
a
name/value
data
list
containing
client
authentication
information.
Input/Output
ident
The
ident
parameter
contains
the
authenticated
user
information.
Return
Values
If
successful,
the
function
returns
XAUTHN_S_COMPLETE.
Other
possible
error
codes
can
be
found
in
the
pdxauthn.h
header
file.
Appendix
A.
External
authentication
C
API
reference
59
xauthn_change_password()
Performs
one
of
two
tasks.
Either
performs
the
password
change,
or
delivers
password
information
to
a
password
strength
server.
Syntax
xauthn_status_t
xauthn_change_password(
xnvlist_t
*authnInfo
);
Description
The
authentication
dispatcher
calls
this
interface
to
implement
a
custom
password
change
mechanism.
This
interface
is
supported
only
for
username/password
and
token
authentication
mechanisms.
Client
password
change
information
is
passed
by
the
dispatcher
through
the
input
argument
authnInfo.
Alternatively,
a
library
implementing
this
interface
can
provide
a
password
strength
mechanism.
Instead
of
actually
updating
a
client
password,
xauthn_change_password()
will
assess
whether
the
client’s
new
password
satisfies
the
mechanism’s
custom
conditions.
The
same
password
change
information
is
included
in
authnInfo
for
both
uses
of
the
interface.
Refer
to
“Obtain
user
authentication
information”
on
page
24
for
the
list
of
authentication
data
that
authnInfo
can
contain.
Parameters
Input
authnInfo
The
authnInfo
parameter
is
a
name/value
data
list
containing
client
authentication
information.
The
possible
authnInfo
identifiers
are
as
follows:
XAUTHN_USERNAME
XAUTHN_PASSWORD
XAUTHN_NEW_PASSWORD
XAUTHN_METHOD
The
XAUTHN_METHOD
identifier
refers
to
the
last
method
used
to
authenticate
the
client.
Its
possible
values
are:
token-card
password
Return
Values
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.
Other
possible
error
codes
can
be
found
in
the
pdxauthn.h
header
file.
When
xauthn_change_password()
is
used
as
a
password-strength
mechanism,
it
returns
XAUTHN_S_COMPLETE
when
the
new
password
satisfies
the
custom
policies.
Any
other
return
code
means
the
strength
check
failed.
Strength
policy
specific
error
codes
are
available
in
the
pdxauthn.h
header
file
to
provide
the
client
useful
messages.
60
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
xauthn_initialize()
Initializes
the
specified
authentication
module
shared
library.
Syntax
xauthn_status_t
xauthn_initialize(
int
argc,
const
char
**argv
);
Description
Use
this
initialization
function
to
initialize
an
authentication
shared
library.
The
input
parameters
argc
and
argv
are
built
from
parameters
specified
in
the
[authentication-mechanisms]
stanza
of
the
secure
Web
server
configuration
file.
The
following
example
definition
uses
the
sample
shared
library:
passwd-ldap
=
libxauthn.so&
-dbms
sys.db
In
the
above
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"
Input
parameters
should
not
be
modified.
WebSEAL
frees
the
contents
of
argc
and
argv.
Therefore,
the
implementer
of
this
function
should
not
free
either
of
these
parameters.
Parameters
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
Values
If
successful,
the
function
returns
XAUTHN_S_COMPLETE.
Other
possible
error
codes
can
be
found
in
the
pdxauthn.h
header
file.
Appendix
A.
External
authentication
C
API
reference
61
xauthn_shutdown()
Shuts
down
the
specified
authentication
module
shared
library.
Syntax
xauthn_status_t
xauthn_shutdown(
int
argc,
const
char
**argv
);
Description
During
the
normal
shutdown,
the
WebSEAL
authentication
dispatcher
calls
this
interface
to
perform
any
shut
down
processes
that
may
required
by
the
custom
environment.
The
input
parameters
argc
and
argv
are
built
from
the
parameters
specified
in
the
[authentication-mechanisms]
stanza
of
the
secure
Web
server
configuration
file.
The
following
example
definition
uses
the
sample
shared
library:
passwd-ldap
=
libxauthn.so&
-dbms
sys.db
In
the
above
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"
Input
parameters
should
not
be
modified.
Parameters
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
Values
If
successful,
the
function
returns
XAUTHN_S_COMPLETE.
Other
possible
error
codes
can
be
found
in
the
pdxauthn.h
header
file.
Note:
The
shutdown
interface
is
not
functional
in
this
release
of
Tivoli
Access
Manager.
You
can
successfully
implement
and
use
the
external
authentication
interface
without
this
function.
62
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
xauthn_util_entry_to_creds()
Converts
a
value
from
an
xnvlist_t
into
a
credential.
Syntax
azn_creds_h_t
xauthn_util_entry_to_creds(
const
char
*value,
int
vlen
);
Description
Some
entries
in
the
xnvlist_t
authentication
data
structure
passed
into
xauthn_authenticate()
and
xauthn_change_password()
are
actually
encoded
credentials.
This
function
converts
the
encoded
credential
into
an
azn_creds_h_t
which
can
then
be
manipulated
using
the
functions
defined
by
the
Tivoli
Access
Manager
authorization
API.
The
caller
does
not
need
to
free
the
returned
azn_creds_h_t.
Parameters
Input
value
The
value
retrieved
by
the
call
to
xnvlist_get()
for
the
entry
which
contains
the
credential.
vlen
The
length
returned
by
the
call
to
xnvlist_get()
for
the
entry
which
contains
the
credential.
Return
Values
The
function
returns
a
valid
credential
if
successful,
or
AZN_C_INVALID_HANDLE
if
an
error
occurs.
Appendix
A.
External
authentication
C
API
reference
63
64
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Appendix
B.
Cross-domain
mapping
framework
C
API
reference
v
“cdmf_add_attr_to_list()”
on
page
66
v
“cdmf_add_value_to_attr()”
on
page
67
v
“cdmf_create_usr_attr()”
on
page
68
v
“cdmf_create_usr_attr_list()”
on
page
69
v
“cdmf_get_usr_attributes()”
on
page
70
v
“cdmf_map_usr()”
on
page
71
v
“CDSSO_FREE()”
on
page
73
v
“CDSSO_MALLOC()”
on
page
74
v
“CDSSO_REALLOC()”
on
page
75
v
“CDSSO_STRDUP()”
on
page
76
©
Copyright
IBM
Corp.
1999,
2003
65
cdmf_add_attr_to_list()
Add
the
specified
user
attribute
to
the
specified
user
attribute
list.
Syntax
int
cdmf_add_attr_to_list(
cdsso_usr_attr_t
*new_attr,
cdsso_attrlist_t
*list
);
Description
Add
the
specified
user
attribute
to
the
specified
user
attribute
list.
The
new
attribute
is
added
to
an
existing
list.
The
caller
is
responsible
for
freeing
memory
used
by
the
attribute
list.
The
new
attribute
is
part
of
the
attribute
list,
and
hence
the
memory
for
it
is
freed
when
the
attribute
list
is
freed.
Parameters
Input
new_attr
New
attribute
to
be
added
to
the
list.
Output
list
Updated
list.
Return
Values
If
successful,
the
function
returns
TRUE.
Otherwise,
the
function
returns
FALSE.
66
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
cdmf_add_value_to_attr()
Add
a
new
value
to
a
user
attribute.
Syntax
int
cdmf_add_value_to_attr(
char
*new_value,
cdsso_usr_attr_t
*attr
);
Description
Add
a
new
value
to
a
user
attribute.
A
copy
of
the
value
is
made.
This
function
can
be
called
many
times
to
add
multiple
values
to
a
user
attribute.
The
caller
is
responsible
for
freeing
the
memory
used
by
the
new
value.
Parameters
Input
new_value
New
value
to
be
added
to
the
attribute.
Output
attr
Updated
user
attribute
object.
Return
Values
If
successful,
the
function
returns
TRUE.
Otherwise,
the
function
returns
FALSE.
Appendix
B.
Cross-domain
mapping
framework
C
API
reference
67
cdmf_create_usr_attr()
Create
a
new
user
attribute.
Syntax
cdsso_usr_attr_t
*
cdmf_create_usr_attr(
char
*attr_name
);
Description
Create
a
new
user
attribute.
A
copy
is
made
of
the
name.
The
caller
is
responsible
for
freeing
the
memory
used
by
the
new
attribute.
Parameters
Input
attr_name
Name
of
the
new
attribute.
Return
Values
If
successful,
the
function
returns
a
pointer
to
the
newly
allocated
attribute.
Otherwise,
the
function
returns
NULL.
68
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
cdmf_create_usr_attr_list()
Create
an
empty
attribute
list.
Syntax
cdsso_attrlist_t
*
cdmf_create_usr_attr_list(
void
);
Description
Create
an
empty
attribute
list.
The
caller
is
responsible
for
freeing
the
memory
used
by
the
list.
Parameters
None.
Return
Values
If
successful,
the
function
returns
a
pointer
to
the
newly
allocated
list.
Otherwise,
the
function
returns
NULL.
Appendix
B.
Cross-domain
mapping
framework
C
API
reference
69
cdmf_get_usr_attributes()
Retrieves
the
extended
attributes
for
the
specified
user.
Syntax
int
cdmf_get_usr_attributes(
char
*usr,
cdsso_attrlist_t
**attr_list
);
Description
WebSEAL
and
Plug-in
for
Web
Servers
calls
this
interface:
v
When
a
CDSSO
request
is
initiated
by
a
user
accessing
the
/pkmscdsso
page
on
the
local
WebSEAL
or
Plug-in
for
Web
Servers
server.
v
When
an
e-community
″vouch
for″
server
generates
a
″vouch
for″
reply
token
for
another
WebSEAL
or
Plug-in
for
Web
Servers
server
in
the
e-community.
In
a
CDSSO
operation,
the
extended
attribute
list
returned
by
this
function
is
sent
to
the
remote
WebSEAL
or
Plug-in
for
Web
Servers
server
(the
target
of
the
request)
inside
the
authentication
token.
In
an
e-community
″vouch
for″
operation,
the
attribute
list
returned
by
this
function
is
sent
to
the
remote
WebSEAL
or
Plug-in
for
Web
Servers
server
(the
target
of
the
request)
inside
the
″vouch
for″
reply
token.
The
remote
WebSEAL
or
Plug-in
for
Web
Servers
server
can
use
these
extended
attributes
to
help
in
the
user
mapping.
The
attribute
list
must
be
constructed
using
the
functions
defined
in
cdmf_utils.h.
If
no
attributes
are
being
set,
this
function
should
set
attr_list
to
NULL.
Note:
WebSEAL
or
Plug-in
for
Web
Servers
frees
the
memory
allocated
by
this
function.
The
implementer
of
the
function
should
not
free
the
pointer
**attr_list.
Parameters
Input
usr
User
name.
Output
attr_list
Extended
attributes
for
input
user.
Return
Values
If
successful,
the
function
returns
CDMF_SUCCESS.
Upon
failure,
the
function
returns
CDMF_FAILURE.
70
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
cdmf_map_usr()
Map
a
remote
user
into
a
local
user.
Syntax
int
cdmf_map_usr(
cdsso_user_info_t
*remote_usr,
cdsso_user_info_t
*local_usr
);
Description
The
WebSEAL
or
Plug-in
for
Web
Servers
CDSSO
token
authentication
(consumption)
mechanism
calls
this
interface
to
determine
the
identity
of
the
local
user
during
a
CDSSO
authentication
or
an
e-community
″vouch
for″
operation.
The
remote
user
information
is
received
in
a
cdsso_usr_info_t
structure.
This
information
includes
the
remote
user
name,
the
remote
domain
name,
and
possibly
an
extended
attribute
list.
This
information
should
be
used
to
determine
the
identity
of
the
local
user.
If
the
local
user’s
identity
is
successfully
determined,
then
CDMF_SUCCESS
should
be
returned.
The
local
user
information
is
returned
in
a
cdsso_usr_info_t
structure.
The
local
user
information
that
can
be
returned
in
this
structure
consists
of
the
local
user
name
and
possibly
an
extended
attribute
list.
If
an
attribute
list
is
to
be
returned,
then
the
functions
defined
in
cdmf_utils.h
should
be
used
to
construct
the
list.
Information
from
this
attribute
list
is
included
in
the
Tivoli
Access
Manager
credential
for
that
client.
When
cdmf_map_user()
successfully
returns
the
user’s
identity,
the
function
should
return
CDMF_SUCCESS.
In
this
case,
the
implementer
of
cdmf_map_user()
should
not
free
the
memory
for
the
cdsso_user_into_t
structure
local_usr.
This
structure
is
freed
by
WebSEAL.
If
cdmf_map_user()
fails,
CDMF_FAILURE
should
be
returned.
If
the
function
completes,
but
is
not
able
to
determine
the
identity
of
the
local
user,
CDMF_NOMAP
should
be
returned.
When
either
CDMF_FAILURE
or
CDMF_NOMAP
is
returned,
WebSEAL
does
not
clean
up
the
memory
used
by
the
cdsso_user_info_t
structure
local_usr.
In
these
cases,
the
implementer
of
cdmf_map_user()
must
clean
up
this
memory.
Parameters
Input
remote_usr
Out
of
domain
user.
Input/Output
local_usr
User
mapped
to
in
this
domain.
Appendix
B.
Cross-domain
mapping
framework
C
API
reference
71
Return
Values
If
successful,
the
function
returns
CDMF_SUCCESS.
If
no
user
mapping
is
available,
the
function
returns
CDMF_NOMAP.
Upon
failure,
the
function
returns
CDMF_FAILURE.
72
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
CDSSO_FREE()
Deallocate
the
specified
memory.
Syntax
void
CDSSO_FREE(
void
*ptr,
);
Description
Deallocate
the
specified
memory.
Parameters
ptr
A
pointer
to
the
memory
to
be
deallocated.
Return
Values
Success:
none.
Error:
none
Appendix
B.
Cross-domain
mapping
framework
C
API
reference
73
CDSSO_MALLOC()
Allocate
a
portion
of
memory
of
the
specified
size.
Syntax
void
*CDSSO_MALLOC(
size_t
size,
);
Description
Allocate
a
portion
of
memory
of
the
specified
size.
The
caller
is
responsible
for
freeing
the
allocated
memory.
Parameters
size
Size
in
bytes
of
memory
to
allocate.
Return
Values
Returns
a
pointer
to
newly
allocated
memory.
Returns
NULL
if
the
call
fails.
74
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
CDSSO_REALLOC()
Reallocate
a
memory
block.
Syntax
void
*CDSSO_REALLOC(
void
*curr_ptr,
size_t
new_size
);
Description
Reallocate
a
memory
block.
The
caller
is
responsible
for
freeing
the
allocated
memory.
Parameters
curr_ptr
Point
to
the
existing
memory
to
be
deallocated.
new_size
Size
in
bytes
of
the
new
portion
of
memory.
Return
Values
Returns
a
pointer
to
the
reallocated
(and
possibly
moved)
memory
block.
Returns
NULL
is
any
memory
errors
are
encountered.
Appendix
B.
Cross-domain
mapping
framework
C
API
reference
75
CDSSO_STRDUP()
Duplicate
the
specified
string.
Syntax
void*
CDSSO_STRDUP(
char
*dest,
char
*src
);
Description
Duplicate
the
specified
string.
The
caller
is
responsible
for
freeing
the
string
when
it
is
no
longer
needed.
Parameters
dest
Destination
string.
src
Source
string.
Return
Values
When
successful,
returns
a
pointer
to
the
new
memory.
Returns
NULL
if
the
call
fails.
76
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Appendix
C.
User
registry
differences
The
following
user
registry
differences
are
known
to
exist
in
this
version
of
IBM
Tivoli
Access
Manager
(Tivoli
Access
Manager.)
1.
When
Tivoli
Access
Manager
is
using
either
Microsoft
Active
Directory
or
a
Lotus
Domino
server
as
its
user
registry,
only
a
single
domain
is
supported.
Use
an
LDAP
user
registry
if
you
wish
to
take
advantage
of
the
multi-domain
support
in
Tivoli
Access
Manager.
2.
Tivoli
Access
Manager
does
not
support
cross
domain
group
membership
or
universal
groups
when
using
Microsoft
Active
Directory
as
its
user
registry.
Importing
such
groups
into
Tivoli
Access
Manager
is
not
supported.
3.
When
the
Tivoli
Access
Manager
policy
server
is
using
either
Microsoft
Active
Directory
or
a
Lotus
Domino
server
as
its
user
registry,
existing
Tivoli
SecureWay
Policy
Director,
Version
3.8
clients
are
not
able
to
connect
to
the
policy
server.
Either
use
a
different
user
registry
or
upgrade
the
clients
to
Tivoli
Access
Manager.
4.
Users
created
in
a
Lotus
Domino
server
or
Microsoft
Active
Directory
user
registry
are
automatically
given
the
capability
to
own
single
signon
credentials
and
this
capability
can
not
be
removed.
When
using
an
LDAP
user
registry,
this
capability
must
be
explicitly
granted
to
a
user
and
subsequently
can
be
removed.
5.
Leading
and
trailing
blanks
in
user
names
and
group
names
are
ignored
when
using
LDAP
or
Microsoft
Active
Directory
as
the
user
registry
in
an
Tivoli
Access
Manager
secure
domain.
However,
when
using
a
Lotus
Domino
server
as
a
user
registry,
leading
and
trailing
blanks
are
significant.
To
ensure
that
processing
is
consistent
regardless
of
what
user
registry
is
being
used,
define
users
and
groups
in
the
user
registry
without
leading
or
trailing
blanks
in
their
names.
6.
The
forward
slash
character
(/)
should
be
avoided
in
user
and
group
names
defined
using
distinguished
name
strings.
The
forward
slash
character
is
treated
differently
in
different
user
registries:
Lotus
Domino
server
Users
and
groups
can
not
be
created
with
names
using
a
distinguished
name
string
containing
a
forward
slash
character.
To
avoid
the
problem,
either
do
not
use
a
forward
slash
character
or
define
the
user
without
using
the
distinguished
name
designation:
pdadmin
user
create
myuser
username/locinfo
test
test
testpwd
instead
of
using
this
one:
pdadmin
user
create
myuser
cn=username/o=locinfo
test
test
testpwd
Microsoft
Active
Directory
Users
and
groups
can
be
created
with
names
using
a
distinguished
name
string
containing
a
forward
slash
character.
However,
subsequent
operations
on
the
object
might
fail
as
some
Active
Directory
functions
interpret
the
forward
slash
character
as
a
separator
between
the
object
name
and
the
host
name.
To
avoid
the
problem,
do
not
use
a
forward
slash
character
to
define
the
user.
7.
When
using
a
multi-domain
Microsoft
Active
Directory
user
registry,
multiple
users
and
groups
can
be
defined
with
the
same
short
name
as
long
as
they
©
Copyright
IBM
Corp.
1999,
2003
77
reside
in
different
domains.
However,
the
full
name
of
the
user
or
group,
including
the
domain
suffix,
must
always
be
specified
to
Tivoli
Access
Manager.
8.
When
using
iPlanet
Version
5.0
as
the
user
registry,
a
user
that
is
created,
added
to
a
group,
and
then
deleted
from
the
user
registry
retains
its
group
membership.
If
a
user
with
the
same
name
is
created
at
some
later
time,
the
new
user
automatically
inherits
the
old
group
membership
and
might
be
given
inappropriate
permissions.
It
is
strongly
recommended
that
the
user
be
removed
from
all
groups
before
the
user
is
deleted.
This
problem
does
not
occur
when
using
the
other
supported
user
registries.
9.
Attempting
to
add
a
single
duplicate
user
to
a
group
does
not
produce
an
error
when
an
LDAP
user
registry
is
being
used.
However,
an
error
is
properly
reflected
when
using
Lotus
Domino
server
or
Microsoft
Active
Directory.
10.
The
Tivoli
Access
Manager
authorization
API
provides
a
credentials
attribute
entitlements
service.
This
service
is
used
to
retrieve
user
attributes
from
a
user
registry.
When
this
service
is
used
with
an
LDAP
user
registry,
the
retrieved
attributes
can
be
either
string
or
binary
data.
However,
when
this
service
is
used
with
a
Microsoft
Active
Directory
or
Lotus
Domino
user
registry,
the
retrieved
attributes
can
be
either
string,
binary
or
integer
data.
11.
The
maximum
lengths
of
various
names
associated
with
Tivoli
Access
Manager
vary
depending
on
the
user
registry
being
used.
See
Table
21
for
a
comparison
of
the
maximum
lengths
allowed
and
the
recommended
maximum
length
to
use
to
ensure
compatibility
with
all
the
user
registries
supported
by
Tivoli
Access
Manager.
Table
21.
Maximum
lengths
for
names
based
on
user
registry
Maximum
length
of:
LDAP
Microsoft
Active
Directory
Lotus
Domino
server
Recommended
maximum
value
First
name
(LDAP
CN)
256
64
960
64
Middle
name
128
64
65535
64
Last
name
(surname)
128
64
960
64
Registry
UID
(LDAP
DN)
1024
2048
255
This
value
is
user
registry-specific
and
must
be
changed
when
changing
user
registries.
Tivoli
Access
Manager
user
identity
256
2048
-
1
-
length_of_
domain_name
200
-
4
-
length_of_
domain_name
This
value
is
user
registry-specific
and
must
be
changed
when
changing
user
registries.
User
password
unlimited
256
unlimited
256
User
description
1024
1024
1024
1024
Group
name
256
256
Group
description
1024
1024
1024
1024
78
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Table
21.
Maximum
lengths
for
names
based
on
user
registry
(continued)
Maximum
length
of:
LDAP
Microsoft
Active
Directory
Lotus
Domino
server
Recommended
maximum
value
Single
signon
resource
name
240
256
256
240
Single
signon
resource
description
1024
1024
1024
1024
Single
signon
user
ID
240
256
256
240
Single
signon
password
unlimited
256
unlimited
256
Single
signon
group
name
240
256
256
240
Single
signon
group
description
1024
1024
1024
1024
Action
name
1
1
1
1
Action
description,
action
type
unlimited
unlimited
unlimited
Object
name,
object
space
name,
ACL
name,
POP
name
unlimited
unlimited
unlimited
Object
description,
object
space
description,
ACL
description,
POP
description
unlimited
unlimited
unlimited
Even
though
some
names
can
be
of
unlimited
length,
excessive
lengths
can
result
in
policy
that
is
difficult
to
manage
and
might
result
in
poor
system
performance.
Choose
maximum
values
that
are
logical
for
your
environment.
Appendix
C.
User
registry
differences
79
80
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
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.
©
Copyright
IBM
Corp.
1999,
2003
81
IBM
may
use
or
distribute
any
of
the
information
you
supply
in
any
way
it
believes
appropriate
without
incurring
any
obligation
to
you.
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
USA
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.
Any
performance
data
contained
herein
was
determined
in
a
controlled
environment.
Therefore,
the
results
obtained
in
other
operating
environments
may
vary
significantly.
Some
measurements
may
have
been
made
on
development-level
systems
and
there
is
no
guarantee
that
these
measurements
will
be
the
same
on
generally
available
systems.
Furthermore,
some
measurement
may
have
been
estimated
through
extrapolation.
Actual
results
may
vary.
Users
of
this
document
should
verify
the
applicable
data
for
their
specific
environment.
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,
82
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
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.
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
SecureWay
Tivoli
Tivoli
logo
WebSphere
Microsoft,
Windows,
Windows
NT,
and
the
Windows
logo
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,
and
service
names
may
be
trademarks
or
service
marks
of
others.
Appendix
D.
Notices
83
84
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
Index
Special
characters[common-modules]
stanza
53
Aamwauthconv
35
authentication
data
structure
22
authentication
modulebuild
custom
library
18
example
library
19
software
requirements
18
specifying
extended
attributes
30
authentication
module
custom
libraryconfigure
and
install
37
authentication
module
example
library
19
authnmech_info
22
CCDMF
APIcomponents
48
customizing
library
49
implementing
custom
library
48
in
a
CDSSO
environment
42
in
an
e-community
environment
42
naming
the
custom
library
file
49
providing
extended
user
attributes
50
providing
identity
mapping
50
software
requirements
48
specifying
extended
attributes
51
understanding
functions
and
macros
13
cdmf_add_attr_to_list()
66
cdmf_add_value_to_attr()
67
cdmf_create_usr_attr_list()
69
cdmf_create_usr_attr()
68
cdmf_get_usr_attributes()
48,
50,
70
cdmf_map_usr()
48,
50,
71
cdmf_utils.h
48
cdmf_utils.lib
48
cdmf.c.examples
48
cdmf.c.skeleton
48
cdmf.h
48
CDSSO
44,
52
definition
40
cdsso_attrlist_t
51
CDSSO_FREE()
73
CDSSO_MALLOC()
74
CDSSO_REALLOC()
75
CDSSO_STRDUP()
76
cdsso_usr_info_t
50
cdsso-argument
41,
53
cdsso-redirect-url
46
cdssotypes.h
48
changing
29
checkingpassword
strength
32
configuration
52
conversion
library
35
configuration
35
convertingcredential
to
string
28
cred-ext-attrs
35
credentialstring
format
28
UTF-8
data
format
34
credential
attributestable
of
15
Ddeprecated
APIspassword
strength
14
displaying
credential
attributes
15
Ee-community
use
of
CDMF
42
EPAC
15
displaying
credential
attributes
15
EPAC
example
application
15
example
library
44
extended
attributes
21,
30,
51
extended
privilege
attribute
certificate
15
external
authentication
APIfunctions
and
data
types
20
External
authentication
APIsoftware
requirements
18
HHTTP_IV_CREDS
in
EPAC
example
15
Iidentifiers
for
authenticationcertificate
25
common
24
HTTP
26
switch
user
26
token
card
26
username/password
25
identity
mappingCDMF
42
Llibcdmfutils
48
libpdxauthn.a
12
library
interface
47
MMakefile.cdmf.in
48
Makefile.in
18
Makefile.win32
48
©
Copyright
IBM
Corp.
1999,
2003
85
Ppassword
strength
14,
32
pdwebpi
49
pdxauthn
18
pdxauthn
libraries
20
pdxauthn_adk
12
pdxauthn.lib
12
pkmscdsso
40
post
password
change
processing
33
pre-authzn
52
Rredirect
requests
52
related
publications
x
Request-URI
24
Ssample
code
30
single
sign-onCDSSO
40
e-community
40
sso-consume
44,
53
sso-create
44,
52
ssocreate
41
switch
user
authentication
26
Ttoken
consume
47
token
consumption
40,
41
token
createlibrary
interface
45
token
creation
40
ssocreate
41
token
librarycreating
45
Uuser
authentication
28
user
password
29
user
registrydifferences
77
maximum
values
78,
79
UTF-8
35
compatibility
34
conversion
library
35
Wwebseald
49
Xxattr_get()
30,
57
xattr_list_item_t
21
xattr_list_t
21,
30
xattr_set()
30,
58
xauthn_admin_cred
24
xauthn_admin_name
24
xauthn_authenticate()
28,
59
xauthn_browser_info
24
xauthn_cert
24
xauthn_cert_dn
24
xauthn_cert_issuer_dn
24
xauthn_change_password()
29,
60
xauthn_existing_cred
24
xauthn_identity_t
21,
28,
30
xauthn_initialize()
20,
61
xauthn_ipaddr
24
xauthn_new_password
24
xauthn_password
24
xauthn_qop
24
xauthn_shutdown()
62
xauthn_su_method
24
xauthn_token
24
xauthn_username
24
xauthn_util_entry_to_creds()
63
xauthn.c
12
xnvlist_get()
45,
56
xnvlist_item_t
22
xnvlist_t
22,
45
86
IBM
Tivoli
Access
Manager
for
e-business:
Web
Security
Developer
Reference
����
Printed
in
USA
SC32-1358-00
![BEA WebLogic Server XΓU - IBMpublib.boulder.ibm.com/tividd/td/ITAME/SC32-1366-01/zh_TW/PDF/am51_wls_guide.pdfw∩ ® IBM ®Tivoli Access Manager for BEA WebLogic Server®]HU Tivoli](https://img.pdfslide.net/doc/110x75/5e87e582a374bd0c512bcb77/bea-weblogic-server-xu-wa-ibm-tivoli-access-manager-for-bea-weblogic.jpg)
