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

More documents

Recommendations

Info

WebSEAL parses the HTML page to identify the request method, the action URI, and any other input fields in the form, and saves them for use in step 8. 8. WebSEAL generates the authentication request (completes the login form) and sends it to the back-end application. 9. The application authenticates the user using the authentication data supplied by WebSEAL in the form. The application returns a redirect to content.html. 10. WebSEAL combines any cookies saved from the responses at step 7 and step 9, and returns these cookies with the redirect to the browser. Note: This completes the forms SSO-specific functionality. 11. The browser follows the redirect and requests: https://webseal/formsso/content.html 12. WebSEAL passes the request to the back-end application across the junction. During this process, the browser makes three requests to WebSEAL. From the user’s perspective, only a single request for https://webseal/formsso/content.html is made. The other requests occur automatically through HTTP redirects. Requirements for application support Single sign-on for forms authentication is supported on applications that meet the following requirements: v The login page or pages for the application must be uniquely identifiable via a single regular expression or several regular expressions. v The login page can include more than one HTML form. However, the login form must be identified by applying a regular expression to the action URIs of each of the login forms, or the login form must be the first form in the login page. Note that when using the ″action″ attribute to identify the login form, the ″action″ attribute has not passed through WebSEAL’s HTML filtering. The regular expression should match the action URI prior to being filtered. v Client-side scripting may be used to validate input data, but it must not modify the input data (such as using Javascript to set cookies in the user’s browser). v Login data is submitted at only one point in the authentication process. v The junction where the authentication request is directed must be the same junction where the login page is returned. Creating the configuration file for forms single sign-on The forms single sign-on configuration file is custom-created by the administrator and saved in any location. The –S option on the junction enables the forms single sign-on functionality and specifies the location of the configuration file. See “Enabling forms single sign-on” on page 332. A sample configuration file (containing commented instructions) is provided with the WebSEAL installation and is located in the following directory: UNIX: /opt/pdweb/etc/fsso.conf.template Windows: C:\Program Files\Tivoli\PDWeb\etc\fsso.conf.template The configuration file must begin with the [forms-sso-login-pages] stanza and has the following format 328 IBM Tivoli Access Manager for e-business: WebSEAL Administration Guide
[forms-sso-login-pages] login-page-stanza = xxxxx> #login-page-stanza = aaaaa> #login-page-stanza = bbbbb> [xxxxx>] login-page = regular-expression-page-match> login-form-action = regular-expression-form-match> gso-resource = gso-target> argument-stanza = yyyyy> [yyyyy>] name> = method>:value> The [forms-sso-login-pages] stanza The forms single sign-on configuration file must always begin with the [forms-sso-login-pages] stanza. The stanza contains one or more login-page-stanza entries that point to other custom-named stanzas that contain configuration information for the login pages found on the back-end application server. The ability to support multiple login pages on a single junction is important because a single back-end server might host several applications that each use a different authentication method. For example: [forms-sso-login-pages] login-page-stanza = loginpage1 login-page-stanza = loginpage2 The custom login page stanza Each custom login page stanza is used to intercept a particular URL pattern. The stanza can contain the following parameters: Parameter Description login-page This parameter specifies a pattern, using a regular expression, that uniquely identifies requests for an application’s login page. WebSEAL intercepts these pages and begins the forms single sign-on process. The regular expression is compared against the request URI and is relative to (and not including) the junction point where the server is mounted. login-form-action This parameter specifies a pattern, using a regular expression, that identifies which form contained in the intercepted page is the application’s login form. If there is only a single form in the page, or if the login form is the first form in the document, then the expression can be ″*>. Otherwise, the regular expression should match the ″action> attribute of the login form. gso-resource This parameter specifies the GSO resource to use when retrieving the GSO user name and password from a GSO database. Leave this parameter blank if GSO is not used to store a GSO user name and password. argument-stanza This parameter points to another custom stanza that lists the fields and data required for completing the login form. For example: Chapter 11. Single sign-on solutions across junctions 329
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 286 and 287:
A user who fails authentication wit
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: 314 IBM Tivoli Access Manager for e
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 358 and 359: [loginpage1] login-page = /cgi-bin/
Page 360 and 361: It is not necessary to specify hidd
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 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 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?