IBM Tivoli Access Manager for e-business: WebSEAL Administration ...

The
default
lifetime
of
data
in
the
WebSEAL
user
cache
is
30
seconds.
This
lifetime
begins
when
the
data
first
enters
the
cache,
such
as
when
a
user
first
authenticates,
or
when
the
cached
data
has
expired
and
WebSEAL
contacts
the
registry
to
update
the
data.
WebSEAL
contacts
the
registry
to
update
the
data
during
a
credential
refresh
event.
The
cached
information
is
valid
for
30
seconds
after
it
is
first
obtained
from
the
registry.
After
30
seconds,
any
credential
refresh
operations
go
directly
to
the
user
registry.
The
access
to
the
user
registry
also
causes
the
user
data
to
be
reloaded
into
the
cache.
The
following
example
shows
the
algorithm
for
updating
the
user
cache:
1.
User
authenticates
at
time
auth_time.
2.
User
is
added
to
a
group
at
time
auth_time
+
120
seconds
3.
User’s
credential
is
refreshed
at
time
auth_time
+
130
seconds
Because
the
user
cache
data
expired
at
time
auth_time
+
30
seconds,
the
new
group
membership
will
be
added
to
the
user’s
credential.
Continuing
with
the
same
example:
1.
User
is
then
added
to
another
group
at
time
auth_time
+
135
seconds
2.
User’s
credential
is
refreshed
at
time
auth_time
+
140
seconds
When
the
user
credential
is
refreshed
at
auth_time
+
140
seconds,
it
does
not
pick
up
the
new
group
membership.
This
is
because
the
user
credential
is
built
off
cached
user
data
when
the
cached
user
data
is
considered
valid
(has
not
expired).
Since
the
user
cache
data
was
updated
at
time
auth_time
+
130
seconds,
it
is
not
scheduled
to
be
updated
until
auth_time
+
160
seconds.
Thus,
the
administrator
must
wait
until
time
auth_time
+
160
seconds
to
run
the
refresh
command.
At
that
time,
the
user
credential
will
pick
up
the
new
group
memberships.
Configuration
file
syntax
and
usage
The
credential
refresh
behavior
is
controlled
by
entries
in
the
[credential-refresh-
attributes]
stanza
in
the
WebSEAL
configuration
file.
The
format
is:
attribute_name_pattern
=
{preserve|refresh}
The
attribute
name
pattern
is
used
to
select
a
given
set
of
attributes.
Wild
card
matching
is
supported.
A
particular
attribute
can
possibly
be
matched
by
many
different
wild
card
patterns.
Therefore,
the
order
of
elements
in
the
configuration
file
is
important.
The
firs
pattern
that
matches
a
given
attribute
is
the
only
pattern
that
applies
to
that
attribute.
Attribute
names
in
attribute_name_pattern
should
not
be
case-sensitive
because
attribute
names
in
credentials
are
not
case-sensitive.
Example
–
Preserve
all
of
the
tag
value
attributes
added
by
an
extended
attribute
CDAS:
[credential-refresh-attributes]
tagvalue_*
=
preserve
Example
–
Update
the
tagvalue_last_refresh_time
attribute
with
the
value
from
the
new
credential,
but
preserve
all
other
attributes
that
begin
with
tagvalue_:
[credential-refresh-attributes]
tagvalue_last_refresh_time
=
refresh
tagvalue_*
=
preserve
222
IBM
Tivoli
Access
Manager
for
e-business:
WebSEAL
Administration
Guide