IBM BS029ML Self Help Guide - Page 111

Security configurations and customizations, 4.2.1 The default security configuration

Page 111 highlights

WebSEAL, a component in Tivoli Access Manager, acts as a reverse proxy server that intercepts all Web requests coming into the portal Web site. When a protected resource is accessed and the user has not been authenticated, WebSEAL challenges the user by consulting with its authorization server (policy server) and the user registry, so the reverse proxy is able to verify the user's identity and pass the user's identity info through iv-user and iv-creds in the HTTP header to WebSphere Application Server. The application server's Trust Association Interceptor then trusts the authentication by retrieving and verifying the user information from the same user registry, and then creates an LTPA token for single sign-on. Two important considerations: Before you can configure the integration with TAM, the security of WebSphere Portal must be configured and single sign-on must be working correctly with the LTPA token. The same user registry must be configured for WebSphere Application Server and TAM. 4.2 Security configurations and customizations Here we discuss some basic configurations and customization scenarios. 4.2.1 The default security configuration WebSphere Portal Version 6 is installed with the security enabled against WMM UR with the WMM database as the user registry. With this setting, the portal is functional right after installation and this configuration is suitable for a simple environment, like unit testing or development. As we specified in 4.1, "Planning and considerations" on page 86, the administrators should seriously consider reconfiguring security with a commercially available LDAP server. If the system will be put into production and performance is a major concern, we do not recommend the database solution and you should reconfigure security as early as possible, so that the impact of the user registry migration can be kept to a minimum. The portal configuration tasks are designed to configure portal security to a default configuration according to the entries in the file wpconfig.properties. It does not deal with more specific customized environments. In these cases, manual modification to the configuration files may be required. The configuration changes we are dealing within these cases are mainly within WMM files and WebSphere Administration Console. WMM requires an external identifier (extId) to be defined and mapped to a unique LDAP server attribute. WMM supports four different member types: Person, Group, Organizational Unit, and Organization. Thus, this external identifier must be mapped to an attribute that all four member types have; otherwise, WMM will fail. Since WebSphere Portal only uses two member types, Person and Group, in most cases, you can disable the support for OrganizationalUnit (OU) and Organization (O) in wmm.xml, wmmLDAPServerAttributes.xml, and wmmAttributes.xml, by simply eliminating the tags or parameters that are related to OU and O. Extending or restricting user populations to include or exclude LDAP branches can be done by adding or deleting search bases, broadening or narrowing the search bases, or adding search filters within the WMM configuration. When you extend the user search bases, you need to be cautious that you do not give access to your portal to some users that are not supposed to have.access to the portal. Chapter 4. WebSphere Portal security 97

  • 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

Chapter 4. WebSphere Portal security
97
WebSEAL, a component in Tivoli Access Manager, acts as a reverse proxy server that
intercepts all Web requests coming into the portal Web site. When a protected resource is
accessed and the user has not been authenticated, WebSEAL challenges the user by
consulting with its authorization server (policy server) and the user registry, so the reverse
proxy is able to verify the user’s identity and pass the user’s identity info through iv-user and
iv-creds in the HTTP header to WebSphere Application Server. The application server’s Trust
Association Interceptor then trusts the authentication by retrieving and verifying the user
information from the same user registry, and then creates an LTPA token for single sign-on.
Two important considerations:
±
Before you can configure the integration with TAM, the security of WebSphere Portal must
be configured and single sign-on must be working correctly with the LTPA token.
±
The same user registry must be configured for WebSphere Application Server and TAM.
4.2
Security configurations and customizations
Here we discuss some basic configurations and customization scenarios.
4.2.1
The default security configuration
WebSphere Portal Version 6 is installed with the security enabled against WMM UR with the
WMM database as the user registry. With this setting, the portal is functional right after
installation and this configuration is suitable for a simple environment, like unit testing or
development.
As we specified in 4.1, “Planning and considerations” on page 86, the administrators should
seriously consider reconfiguring security with a commercially available LDAP server. If the
system will be put into production and performance is a major concern, we do not recommend
the database solution and you should reconfigure security as early as possible, so that the
impact of the user registry migration can be kept to a minimum.
The portal configuration tasks are designed to configure portal security to a default
configuration according to the entries in the file wpconfig.properties. It does not deal with
more specific customized environments. In these cases, manual modification to the
configuration files may be required. The configuration changes we are dealing within these
cases are mainly within WMM files and WebSphere Administration Console.
WMM requires an external identifier (extId) to be defined and mapped to a unique LDAP
server attribute. WMM supports four different member types: Person, Group, Organizational
Unit, and Organization. Thus, this external identifier must be mapped to an attribute that all
four member types have; otherwise, WMM will fail. Since WebSphere Portal only uses two
member types, Person and Group, in most cases, you can disable the support for
OrganizationalUnit (OU) and Organization (O) in wmm.xml, wmmLDAPServerAttributes.xml,
and wmmAttributes.xml, by simply eliminating the tags or parameters that are related to OU
and O.
Extending or restricting user populations to include or exclude LDAP branches can be done
by adding or deleting search bases, broadening or narrowing the search bases, or adding
search filters within the WMM configuration. When you extend the user search bases, you
need to be cautious that you do not give access to your portal to some users that are not
supposed to have.access to the portal.