IBM BS029ML Self Help Guide - Page 102

memberDN, memberUniqueId, for IBM Tivoli Directory Server, or - jobs

Page 102 highlights

Currently, WMM support the following major commercial LDAP servers: IBM Tivoli Directory Server Microsoft® Active Directory® SunOne Directory Server IBM Lotus Domino Application Server Novell eDirectory WMM implements the wmmLDAP as an abstraction layer, in which for each type of the supported LDAP servers, WMM provides an adapter module to shield the implementation details of the LDAP servers from application developers. This way, it is able to provide a standard set of Member Repository APIs for applications, like WebSphere Portal, to manage uses and groups. Optionally, you can use a look-aside profile repository adapter to interact with a look-aside repository using one of the available commercial databases with a schema defined by the Member Manager. The look-aside repository is used to store member attributes that cannot be stored in the member's main profile repository (such as the wmmLDAP). In Member Manager, the look-aside repository is referred to as wmmLookAside and the adapter is referred to as the wmmLookAside adapter. Although you can technically use wmmLookAside in conjunction with wmmDB repository, it is likely unnecessary, since all functionalities supported by the wmmLookAside is also supported by wmmDB. Every member managed by Member Manager requires a unique identifier. A unique identifier allows a member profile to be easily retrieved. Member Manager provides two types of unique identifiers: memberDN is a distinguished name for a member, and is convenient for identification and display purposes. memberDN is unique and may be changed and reused. After a member is deleted from Member Manager, a new member can be created and reuse the memberDN of the deleted member. An example of a memberDN of a Person "Jane Doe" is "uid=janedoe,ou=people,ou=sales,o=acme.com". memberUniqueId is unique, static, and never reused. That is, once memberUniqueId for a member is created, the value of that memberUniqueId will not be changed, even if the member is deleted. A new member cannot reuse the value of the memberUniqueId of the deleted member. The memberDN therefore uniquely identifies a member at a single point in time while the memberUniqueId, due to its characteristic of never being reused, uniquely identifies a member over time. In the example above, the person "Jane Doe" may change a job and work for a new organizational unit "marketing", so the new memberDN then becomes "uid=janedoe,ou=people,ou=marketing,o=acme.com", but the memberUniqueId is still the same. The memberUniqueId in WMM can be mapped to a unique attribute in the LDAP server. The examples of memberUniqueId might be ibm-entryUUID for IBM Tivoli Directory Server, or objectGUID for Microsoft Active Directory. Depending on your usage of member profile data, you may want to use the memberDN or both the memberDN and the memberUniqueId. Since memberDN values are readable, they are suitable for display purpose. The memberUniqueId values are not guaranteed to be readable and therefore may be unsuitable for display. Since a memberDN can be changed and reused, if your application receives a memberDN from Member Manager, puts the memberDN in some form of storage, and subsequently uses that memberDN with Member Manager, there is no guarantee that memberDN will not refer to a different member than the one to which it previously referred. 88 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

88
IBM WebSphere Portal V6 Self Help Guide
Currently, WMM support the following major commercial LDAP servers:
±
IBM Tivoli Directory Server
±
Microsoft® Active Directory®
±
SunOne Directory Server
±
IBM Lotus Domino Application Server
±
Novell eDirectory
WMM implements the wmmLDAP as an abstraction layer, in which for each type of the
supported LDAP servers, WMM provides an adapter module to shield the implementation
details of the LDAP servers from application developers. This way, it is able to provide a
standard set of Member Repository APIs for applications, like WebSphere Portal, to manage
uses and groups.
Optionally, you can use a look-aside profile repository adapter to interact with a look-aside
repository using one of the available commercial databases with a schema defined by the
Member Manager. The look-aside repository is used to store member attributes that cannot
be stored in the member’s main profile repository (such as the wmmLDAP). In Member
Manager, the look-aside repository is referred to as wmmLookAside and the adapter is
referred to as the wmmLookAside adapter. Although you can technically use wmmLookAside
in conjunction with wmmDB repository, it is likely unnecessary, since all functionalities
supported by the wmmLookAside is also supported by wmmDB.
Every member managed by Member Manager requires a unique identifier. A unique identifier
allows a member profile to be easily retrieved. Member Manager provides two types of unique
identifiers:
±
memberDN
is a distinguished name for a member, and is convenient for identification and
display purposes. memberDN is unique and may be changed and reused. After a member
is deleted from Member Manager, a new member can be created and reuse the
memberDN of the deleted member. An example of a memberDN of a Person “Jane Doe” is
“uid=janedoe,ou=people,ou=sales,o=acme.com”.
±
memberUniqueId
is unique, static, and never reused. That is, once memberUniqueId for a
member is created, the value of that memberUniqueId will not be changed, even if the
member is deleted. A new member cannot reuse the value of the memberUniqueId of the
deleted member.
The memberDN therefore uniquely identifies a member at a single point in time while the
memberUniqueId, due to its characteristic of never being reused, uniquely identifies a
member over time. In the example above, the person “Jane Doe” may change a job and work
for a new organizational unit “marketing”, so the new memberDN then becomes
“uid=janedoe,ou=people,ou=marketing,o=acme.com”, but the memberUniqueId is still the
same.
The memberUniqueId in WMM can be mapped to a unique attribute in the LDAP server. The
examples of memberUniqueId might be
ibm-entryUUID
for IBM Tivoli Directory Server, or
objectGUID
for Microsoft Active Directory.
Depending on your usage of member profile data, you may want to use the memberDN or
both the memberDN and the memberUniqueId.
Since memberDN values are readable, they are suitable for display purpose. The
memberUniqueId values are not guaranteed to be readable and therefore may be unsuitable
for display. Since a memberDN can be changed and reused, if your application receives a
memberDN from Member Manager, puts the memberDN in some form of storage, and
subsequently uses that memberDN with Member Manager, there is no guarantee that
memberDN will not refer to a different member than the one to which it previously referred.