IBM BS029ML Self Help Guide - Page 54

Trust Association with WebSEAL, Single sign-off

Page 54 highlights

Single sign-off One often neglected aspect of SSO is the allied sign-off or sign out action associated with a user session. This is especially important because it is not uncommon for the back-end servers participating in the SSO realm to create and issue their own authentication cookies as part of the transparent SSO process. Unfortunately, if a user explicitly logs out of WebSEAL, but does not close or terminate the browser session, the back-end server cookies will remain active within the browser session. This, then creates a security threat by raising the risk that an unauthorized user may gain access to restrictive information, although it should be acknowledged that this kind of threat is only applicable to shared desktops and workstations, such as kiosks. To overcome this threat, the recommendation is to embed JavaScript code capable of searching and destroying all applicable cookies in the page that WebSEAL redirects to after logging out a user. 2.6.4 Trust Association with WebSEAL In this configuration, the underlying WebSphere Application Server instance of WebSphere Portal Server needs to be configured to explicitly "trust" the WebSEAL server so that if WebSEAL has already authenticated a user, WebSphere Application Server will not challenge the user to authenticate again. WebSphere Application Server provides a Trust Association Interceptor (TAI) framework for this purpose. Based on the established trust, WebSphere Application Server can map the delegated credential from WebSEAL to a valid WebSphere Application Server credential. The identification of the user must be passed to the TAI in a header called iv-user, which is inserted by WebSEAL into the HTTP Header of the request sent from WebSEAL to the WebSphere Application Server. Note that while WebSEAL can be configured to pass the user identity in other ways, the iv-user header is the only one supported by the TAI. Also note that the user password is not passed in the HTTP Header (for security reasons). After the TAI processing is successful, WebSphere Application Server creates a user authentication cookie called an LTPA token (we recommend using the LTPA token2). This is identical to the process that occurs when the out-of-the-box SSO with WebSphere Portal Server is enabled. With the availability of the new TAI++, TAI now does not query the User Registry (LDAP) directly for Trust Association Interceptor processing. Instead, the new Interceptor class TAMTrustAssociationInterceptorplus contacts the Tivoli Access Manager (TAM) Authorization Server, which then proceeds to check the User Registry (LDAP). The benefit that this brings to a solution is that the TAM Authorization Server does not have to be the actual TAM Policy Server. As such, a local TAM Authorization Server replica can be installed, either alongside each WebSphere Portal Server node, or on an additional number of dedicated servers. As one might expect, this requires an additional amount of effort and planning, not to mention system resources. However, this is very beneficial when overall performance is a concern, as requests can be offloaded and cached at the TAM Authorization Server replicas, which may or may not be local to each WebSphere Portal Server node, greatly improving performance. After successful processing, TAI++ adds the PDPrincipal to the WebSphere subject or context, which can be retrieved by downstream applications. Furthermore, with the new TAI++, one can add custom attributes to the subject or context in the form of Java sets. After the TAI++ has accepted the user identification and WebSphere Application Server has created the LTPA token, the WebSphere Member Manager component of WebSphere Portal Server performs additional queries against the User Registry (LDAP). In particular, WebSphere Member Manager does an LDAP search to get group and additional attribute information from the LDAP. WebSphere Portal Server also queries the resource mappings from the Portal database, before displaying the applicable Portal pages. 40 IBM WebSphere Portal V6 Self Help Guide

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242

40
IBM WebSphere Portal V6 Self Help Guide
Single sign-off
One often neglected aspect of SSO is the allied sign-off or sign out action associated with a
user session. This is especially important because it is not uncommon for the back-end
servers participating in the SSO realm to create and issue their own authentication cookies as
part of the transparent SSO process. Unfortunately, if a user explicitly logs out of WebSEAL,
but does not close or terminate the browser session, the back-end server cookies will remain
active within the browser session. This, then creates a security threat by raising the risk that
an unauthorized user may gain access to restrictive information, although it should be
acknowledged that this kind of threat is only applicable to shared desktops and workstations,
such as kiosks.
To overcome this threat, the recommendation is to embed JavaScript code capable of
searching and destroying all applicable cookies in the page that WebSEAL redirects to after
logging out a user.
2.6.4
Trust Association with WebSEAL
In this configuration, the underlying WebSphere Application Server instance of WebSphere
Portal Server needs to be configured to explicitly "trust" the WebSEAL server so that if
WebSEAL has already authenticated a user, WebSphere Application Server will not
challenge the user to authenticate again. WebSphere Application Server provides a Trust
Association Interceptor (TAI) framework for this purpose. Based on the established trust,
WebSphere Application Server can map the delegated credential from WebSEAL to a valid
WebSphere Application Server credential. The identification of the user must be passed to
the TAI in a header called iv-user, which is inserted by WebSEAL into the HTTP Header of the
request sent from WebSEAL to the WebSphere Application Server. Note that while WebSEAL
can be configured to pass the user identity in other ways, the iv-user header is the only one
supported by the TAI. Also note that the user password is not passed in the HTTP Header (for
security reasons). After the TAI processing is successful, WebSphere Application Server
creates a user authentication cookie called an LTPA token (we recommend using the LTPA
token2). This is identical to the process that occurs when the out-of-the-box SSO with
WebSphere Portal Server is enabled.
With the availability of the new TAI++, TAI now does not query the User Registry (LDAP)
directly for Trust Association Interceptor processing. Instead, the new Interceptor class
TAMTrustAssociationInterceptorplus contacts the Tivoli Access Manager (TAM) Authorization
Server, which then proceeds to check the User Registry (LDAP). The benefit that this brings
to a solution is that the TAM Authorization Server does not have to be the actual TAM Policy
Server. As such, a local TAM Authorization Server replica can be installed, either alongside
each WebSphere Portal Server node, or on an additional number of dedicated servers. As
one might expect, this requires an additional amount of effort and planning, not to mention
system resources. However, this is very beneficial when overall performance is a concern, as
requests can be offloaded and cached at the TAM Authorization Server replicas, which may
or may not be local to each WebSphere Portal Server node, greatly improving performance.
After successful processing, TAI++ adds the PDPrincipal to the WebSphere subject or
context, which can be retrieved by downstream applications. Furthermore, with the new
TAI++, one can add custom attributes to the subject or context in the form of Java sets.
After the TAI++ has accepted the user identification and WebSphere Application Server has
created the LTPA token, the WebSphere Member Manager component of WebSphere Portal
Server performs additional queries against the User Registry (LDAP). In particular,
WebSphere Member Manager does an LDAP search to get group and additional attribute
information from the LDAP. WebSphere Portal Server also queries the resource mappings
from the Portal database, before displaying the applicable Portal pages.