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

More documents

Recommendations

Info

A user who fails authentication with the MAS when requesting a resource in a non-MAS (but participating) domain is given the option to authenticate to the local server where the request is being made. v The MAS (and eventually other selected servers in the remote domains) ″vouch for″ the user’s authenticated identity. v Domain-specific cookies are used to identify the server that can provide ″vouch for″ services. This allows servers in a remote domain to request ″vouch for″ information locally. The encrypted contents of e-community cookies do not contain user identity or security information. v Special tokens are used to pass encrypted ″vouched for″ user identity. The ″vouch for″ token does not contain actual user authentication information. Integrity is provided by shared secret key (triple-DES). The token contains a time-out (lifetime) value to limit the duration of the token validity. e-community process flow An e-community consists of a master authentication WebSEAL server (MAS) and additional WebSEAL servers located in the home domain and remote domains. The MAS can exist as a single instance of a WebSEAL server, or a set of WebSEAL replicas located behind a load balancer (where the load balancer is identified as the MAS). All participating local and remote WebSEAL servers need to be configured to use the home domain MAS for initial client authentication. This is a hard requirement for servers in the home domain, and a soft requirement for servers in remote domains. For example, some servers in remote domains can be configured to handle their own authentication. These servers, and the resources they protect, can operate independently of the e-community, even if they are located in a participating e-community domain. The e-community implementation is based on a ″vouch for″ system. Normally, when a user requests a resource from a WebSEAL server where the user has not established a valid session, WebSEAL prompts the user for authentication information. In an e-community configuration, the WebSEAL server identifies a ″vouch for″ server and requests verification from this ″vouch for″ server that the user has authenticated. The ″vouch for″ server has valid credential information for that user. For the user’s first request, the ″vouch for″ server is always the MAS. The MAS continues to serve as the ″vouch for″ server for resources located in the home domain. As the user continues with resource requests across the e-community, an individual server in each remote domain can build its own credential for the user (based on user identity information from the MAS) and assume the role of ″vouch for″ server for resources in its domain. The verification requested of the ″vouch for″ server takes the form of a ″vouch for″ token. The ″vouch for″ server creates the token and returns it to the requesting WebSEAL server. The user identity information in the token is encrypted. The token contains a lifetime limit. Upon receipt of the ″vouch for″ token, the requesting server builds credentials and a local session for that user. The user can now access the requested resource based on normal authorization controls. The user benefits from not having to re-authenticate—a goal of the e-community model. 258 IBM Tivoli Access Manager for e-business: WebSEAL Administration Guide
Refer to the following diagram as you follow the e-community process flow in the remainder of this section. The process flow describes two possible FIRST access scenarios (1 and 2). These are followed by two possible NEXT access scenarios (3 and 4) which follow immediately after 2 or 3. Scenario 5 occurs any time after the initial access. ″Vouch For″ Servers v The MAS is always used to authenticate a user accessing any part of the e-community for the first time. The MAS should perform only as an authentication server and not as a resource provider. The MAS should not be configured to act as a master authentication server and, simultaneously, protect resources. This recommendation addresses performance concerns and is not a security requirement. v The MAS is always the ″vouch for″ server for the home domain (domain A in this example). v A domain-specific e-community cookie is used to identify the ″vouch for″ server for all other servers within a given domain. The ″vouch for″ server is the first server in a domain that requests a ″vouch for″ token from the MAS. The ″vouch for″ server provides ″vouch for″ information for the user within the domain. Subsequent requests for ″vouch for″ services in a given remote domain can be made locally by this server, rather than accessing the out-of-domain MAS. In the home domain, the e-community cookie identifies the MAS as the ″vouch for″ server. (1) FIRST e-Community Local (Domain A) Access: WebSEAL 1 1. User requests a resource protected by WebSEAL 1 (within the same domain as MAS). The browser contains no e-community cookie for this domain. WebSEAL 1 has no cached credentials for the user. 2. WebSEAL 1 configuration has e-community authentication enabled and specifies the location of the MAS. WebSEAL 1 redirects the browser to a special ″vouch for″ URL on the MAS. 3. The MAS receives the ″vouch for″ request and, failing to find credentials for that user, prompts the user to login. Client Domain A Domain B mas.dA.com ws1.dA.com ws2.dA.com WebSEAL 1 WebSEAL 2 WebSEAL MAS ws3.dB.com ws4.dB.com WebSEAL 3 WebSEAL 4 Figure 10. e-community process flow Chapter 9. Client single sign-on solutions 259
Page 1:
IBM Tivoli Access Manager for e-bus
Page 4 and 5:
Note Before using this information
Page 6 and 7:
Silent configuration overview . . .
Page 8 and 9:
Event capturing and logging . . . .
Page 10 and 11:
Token authentication concepts . . .
Page 12 and 13:
Configuring WebSEAL key database pa
Page 14 and 15:
Preserving cookie names . . . . . .
Page 16 and 17:
Logging . . . . . . . . . . . . . .
Page 18 and 19:
xvi IBM Tivoli Access Manager for e
Page 20 and 21:
This chapter introduces you to impo
Page 22 and 23:
Web security information v IBM Tivo
Page 24 and 25:
v Secure Sockets Layer Introduction
Page 26 and 27:
The following documents associated
Page 28 and 29:
Monospace Code examples, command li
Page 30 and 31:
IBM Tivoli Access Manager WebSEAL:
Page 32 and 33:
The access control list (ACL) An ac
Page 34 and 35:
Note: Traditional applications bund
Page 36 and 37:
v Authenticated clients access usin
Page 38 and 39:
v A user makes a request for a reso
Page 40 and 41:
A unified Web space simplifies the
Page 42 and 43:
14 IBM Tivoli Access Manager for e-
Page 44 and 45:
Server instance configuration This
Page 46 and 47:
Table 1. WebSEAL instances sharing
Page 48 and 49:
- When the Web document root is not
Page 50 and 51:
-ssl_yn ssl_enable_yes_no -key_file
Page 52 and 53:
Server instance configuration tasks
Page 54 and 55:
Removing a server instance To remov
Page 56 and 57:
Communication protocol configuratio
Page 58 and 59:
Restricting connections from specif
Page 60 and 61:
Cryptographic hardware for encrypti
Page 62 and 63:
You can specify whether to enable F
Page 64 and 65:
3. In the Open dialog window, selec
Page 66 and 67:
Quality of protection levels You ca
Page 68 and 69:
Configuring authorization database
Page 70 and 71:
3. Change the settings for the data
Page 72 and 73:
Multi-locale support with UTF-8 Thi
Page 74 and 75:
WebSEAL generates logging and audit
Page 76 and 77:
Configuring multi-locale support Co
Page 78 and 79:
WebSEAL does not recognize UTF-8 en
Page 80 and 81:
ackwards compatibility, the format
Page 82 and 83:
Language System Directory English (
Page 84 and 85:
Preventing vulnerability caused by
Page 86 and 87:
Replicated front-end WebSEAL server
Page 88 and 89:
The session cookie links to session
Page 90 and 91:
Table 4. P3P default header values
Page 92 and 93:
Table 6. Supported values for the c
Page 94 and 95:
For each value specified for purpos
Page 96 and 97:
example, when your compact policy s
Page 98 and 99:
70 IBM Tivoli Access Manager for e-
Page 100 and 101:
Server tasks Start a WebSEAL server
Page 102 and 103:
Managing the Web space The followin
Page 104 and 105:
You can configure the specific grap
Page 106 and 107:
Parameter Description cache-type Sp
Page 108 and 109:
HTTP data compression WebSEAL serve
Page 110 and 111:
Compression policy in POPs You can
Page 112 and 113:
HTTP error message pages When WebSE
Page 114 and 115:
Filename Title Description HTTP Err
Page 116 and 117:
Managing custom account management
Page 118 and 119:
Macro Description %CERTAUTHN% Subst
Page 120 and 121:
Backup and restore Tivoli Access Ma
Page 122 and 123:
Problem determination tools for Web
Page 124 and 125:
Logging WebSEAL serviceability mess
Page 126 and 127:
Event capturing and logging You can
Page 128 and 129:
In this example, none of the option
Page 130 and 131:
Authentication event log output Aut
Page 132 and 133:
Table 18. Authentication errors (co
Page 134 and 135:
Log Files Location Parameter Enable
Page 136 and 137:
Displaying referer.log The referer.
Page 138 and 139:
WebSEAL-specific ACL policies The f
Page 140 and 141:
Configuring three strikes login pol
Page 142 and 143:
Configuring password strength polic
Page 144 and 145:
Specific user and global settings T
Page 146 and 147:
v token authentication v certificat
Page 148 and 149:
The entry level = unauthenticated m
Page 150 and 151:
Table 20. Example integer values fo
Page 152 and 153:
pdadmin> pop modify test set ipauth
Page 154 and 155:
Quality of protection POP policy Th
Page 156 and 157:
128 IBM Tivoli Access Manager for e
Page 158 and 159:
Overview of the authentication proc
Page 160 and 161:
Managing session state A secure con
Page 162 and 163:
This value corresponds to the numbe
Page 164 and 165:
eauthenticating the user. WebSEAL u
Page 166 and 167:
v Because the cookies are available
Page 168 and 169:
Authentication configuration overvi
Page 170 and 171:
Configuring multiple authentication
Page 172 and 173:
3. When the client makes an additio
Page 174 and 175:
You can configure the username and
Page 176 and 177:
Configuration conditions If forms a
Page 178 and 179:
If the security policy does require
Page 180 and 181:
Setting Description accept-client-c
Page 182 and 183:
Thus, the default value for cert-ca
Page 184 and 185:
HTTP header authentication Tivoli A
Page 186 and 187:
See also: v “Authentication metho
Page 188 and 189:
Token authentication Tivoli Access
Page 190 and 191:
2. WebSEAL returns an authenticatio
Page 192 and 193:
4. Restart the WebSEAL server. See
Page 194 and 195:
Failover authentication This sectio
Page 196 and 197:
authenticates using forms authentic
Page 198 and 199:
Administrators can configure WebSEA
Page 200 and 201:
cookie. By using the cookie, the We
Page 202 and 203:
Specify the protocol for failover c
Page 204 and 205:
Backwards compatibility WebSEAL ser
Page 206 and 207:
[failover-add-attributes] attribute
Page 208 and 209:
v When this value is no, and the se
Page 210 and 211:
SPNEGO protocol and Kerberos authen
Page 212 and 213:
v The client cannot use an SSL sess
Page 214 and 215:
Page 216 and 217:
Switch user authentication The WebS
Page 218 and 219:
9. The administrator ends the switc
Page 220 and 221:
supported mechanism, an additional
Page 222 and 223:
The authentication method parameter
Page 224 and 225:
The default file name is switchuser
Page 226 and 227:
xauthn_username xauthn_qop xauthn_i
Page 228 and 229:
Server-side request caching This se
Page 230 and 231:
v “Modifying request-body-max-rea
Page 232 and 233:
Configuring reauthentication based
Page 234 and 235:
Extending the session cache entry l
Page 236 and 237: Configuring reauthentication based
Page 238 and 239: Extending the session cache entry l
Page 240 and 241: Automatic redirection during user l
Page 242 and 243: Configuring post password change pr
Page 244 and 245: WebSEAL provides an external authen
Page 246 and 247: credattrs_email joeuser@bigco.com c
Page 248 and 249: Credential refresh This section con
Page 250 and 251: The default lifetime of data in the
Page 252 and 253: Credential refresh configuration To
Page 254 and 255: efresh can succeed. Likewise, when
Page 256 and 257: Managing client-side and server-sid
Page 258 and 259: At installation, WebSEAL uses the s
Page 260 and 261: Setting the maximum number of cache
Page 262 and 263: Windows desktop single sign-on This
Page 264 and 265: v Failover authentication The failo
Page 266 and 267: Each WebSEAL instance must have a s
Page 268 and 269: highly secure password, such as a r
Page 270 and 271: Note: The location of the kinit uti
Page 272 and 273: v When a problem occurs, consider e
Page 274 and 275: The link contains a special CDSSO m
Page 276 and 277: 2. Edit /etc/nsswitch.conf so the h
Page 278 and 279: [authentication-mechanisms] sso-cre
Page 280 and 281: http://websealB/resource.html?PD-ID
Page 282 and 283: Each entry in the WebSEAL is assign
Page 284 and 285: e-community single sign-on E-commun
Page 288 and 289: 4. After successful login, the MAS
Page 290 and 291: v The domain-specific cookie contai
Page 292 and 293: owser is Microsoft Internet Explore
Page 294 and 295: 1. Enabling and disabling e-communi
Page 296 and 297: [e-community-domain-keys] dA.com =
Page 298 and 299: For example: [e-community-sso] vf-u
Page 300 and 301: [server] pre-510-compatible-tokens
Page 302 and 303: [ecsso-incoming-attributes] my_spec
Page 304 and 305: WebSEAL junctions overview You can
Page 306 and 307: Managing junctions with Web Portal
Page 308 and 309: Configuring a basic WebSEAL junctio
Page 310 and 311: Mutually authenticated SSL junction
Page 312 and 313: v It is highly recommended that you
Page 314 and 315: WebSEAL-to-WebSEAL junctions over S
Page 316 and 317: v “Processing URLs in requests”
Page 318 and 319: Modifying absolute URLs with script
Page 320 and 321: To solve this problem: 1. Always wr
Page 322 and 323: You must create the jmt.conf mappin
Page 324 and 325: Part 2: -j junctions modify Set-Coo
Page 326 and 327: Supplying client identity in HTTP h
Page 328 and 329: [junction] max-webseal-header-size
Page 330 and 331: ack-end server UUID to each front-e
Page 332 and 333: v Back-end server 2 is called APP2
Page 334 and 335: lcp_uri URI encoded local code page
Page 336 and 337:
v Do not mark any certificate in th
Page 338 and 339:
1. Copy query_contents.sh into a fu
Page 340 and 341:
Typical output looks like: 100 inde
Page 342 and 343:
Page 344 and 345:
Configuring BA headers for single s
Page 346 and 347:
Forwarding original client BA heade
Page 348 and 349:
Using global sign-on (GSO) Tivoli A
Page 350 and 351:
Configuring a GSO-enabled WebSEAL j
Page 352 and 353:
Configuring single sign-on to IBM W
Page 354 and 355:
Configuring single sign-on forms au
Page 356 and 357:
WebSEAL parses the HTML page to ide
Page 358 and 359:
[loginpage1] login-page = /cgi-bin/
Page 360 and 361:
It is not necessary to specify hidd
Page 362 and 363:
Page 364 and 365:
Supporting CGI programming To suppo
Page 366 and 367:
Supporting back-end server-side app
Page 368 and 369:
v Short name of the server v IP add
Page 370 and 371:
pdadmin> objectspace create /Resour
Page 372 and 373:
A single user that logs in multiple
Page 374 and 375:
346 IBM automatically with no user
Page 376 and 377:
Note: If you use Web Portal Manager
Page 378 and 379:
Object Space Entry URL Template /ow
Page 380 and 381:
The following sample dynurl.conf fi
Page 382 and 383:
The security policy To provide suit
Page 384 and 385:
Page 386 and 387:
Overview of ADI retrieval The Tivol
Page 388 and 389:
The resource-manager-provided-adi p
Page 390 and 391:
Retrieving ADI from the user creden
Page 392 and 393:
Dynamic ADI retrieval Rules can be
Page 394 and 395:
Page 396 and 397:
Basic configuration Basic configura
Page 398 and 399:
trace_verbose_get_entitlement If se
Page 400 and 401:
Erandt_Securtities_Entitlements e
Page 402 and 403:
http://ese.erant.com/attributes 1 U
Page 404 and 405:
376 IBM v v /opt/pdwebars/protocol_
Page 406 and 407:
Windows C:\Program Files\Tivoli\PDW
Page 408 and 409:
including tracking CGI types, compi
Page 410 and 411:
Stanza organization The remainder o
Page 412 and 413:
Server configuration v [server] v [
Page 414 and 415:
HTTP/1.1 connection timeout, in sec
Page 416 and 417:
Location of the file that contains
Page 418 and 419:
Enable or disable support for UTF-8
Page 420 and 421:
Specifies how WebSEAL responds to r
Page 422 and 423:
Host name of the LDAP server. The W
Page 424 and 425:
cache-group-expire-time = number_of
Page 426 and 427:
String that specifies the key label
Page 428 and 429:
Active Directory [uraf-ad] stanza a
Page 430 and 431:
ind-pwd = admin_password Encoded ad
Page 432 and 433:
LDAP port number for the Lotus Domi
Page 434 and 435:
Secure Socket Layer [ssl] stanza we
Page 436 and 437:
Disables support for SSL Version 2.
Page 438 and 439:
Port number for communication with
Page 440 and 441:
Indicates whether automatic refresh
Page 442 and 443:
Authentication methods [ba] stanza
Page 444 and 445:
Specifies how to handle certificate
Page 446 and 447:
Step-up authentication levels. WebS
Page 448 and 449:
Fully qualified path for a library
Page 450 and 451:
failover-certificate = fully_qualif
Page 452 and 453:
Authentication failover v [failover
Page 454 and 455:
List of attributes from the origina
Page 456 and 457:
Cross-domain single sign-on v [cdss
Page 458 and 459:
attribute_pattern = {preserve|refre
Page 460 and 461:
Integer value specifying the port n
Page 462 and 463:
File names for keys for any domains
Page 464 and 465:
List of string values to specify th
Page 466 and 467:
Integer value for lifetime, in seco
Page 468 and 469:
Content This section contains the f
Page 470 and 471:
Specifies how standard WebSEAL HTML
Page 472 and 473:
Page containing a change password f
Page 474 and 475:
Automatic redirect v [acnt-mgt] v [
Page 476 and 477:
List containing system environment
Page 478 and 479:
Relative path name to a graphics fi
Page 480 and 481:
Content compression v [compress-mim
Page 482 and 483:
Content encodings [content-encoding
Page 484 and 485:
Junction management [junction] stan
Page 486 and 487:
Positive integer value indicating t
Page 488 and 489:
Document filtering [filter-url] sta
Page 490 and 491:
Scheme filtering [filter-schemes] s
Page 492 and 493:
Script filtering v [script-filterin
Page 494 and 495:
Credential refresh [credential-refr
Page 496 and 497:
Integer value that specifies the ti
Page 498 and 499:
Integer value that specifies the ti
Page 500 and 501:
Enables or disables the requests lo
Page 502 and 503:
Auditing [aznapi-configuration] sta
Page 504 and 505:
Specifies event logging for the spe
Page 506 and 507:
The maximum size of the in-memory p
Page 508 and 509:
Policy server v [policy-director] v
Page 510 and 511:
Specifies the type of access the us
Page 512 and 513:
v state Mechanisms for maintaining
Page 514 and 515:
Specifies the purpose of the inform
Page 516 and 517:
Specifies the recipients of the inf
Page 518 and 519:
Page 520 and 521:
For example, if the configured name
Page 522 and 523:
-p port TCP port of the back-end th
Page 524 and 525:
Page 526 and 527:
IBM may use or distribute any of th
Page 528 and 529:
Page 530 and 531:
asic authentication configuring 145
Page 532 and 533:
F failover authentication configura
Page 534 and 535:
key management (continued) managing
Page 536 and 537:
eauthentication (continued) based o
Page 538:
User Registry Adapter Framework (UR
show all

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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?