IBM Connections user ids

Question

I'm currently confused by the IDs identifying a user in Connections, and their link to the underlying LDAP directory. So far, I identified several ids:

1. email: simple but not reliable as email access might have been disabled by the admin. This is particularly true for Connections cloud.
2. snx:userid: UUID generated by Connections, but this is the chicken and egg. To find the userid, you need to first get access to a profile document, or some data retrieved from Connections
3. key: also generated by Connections, but I don't get the pattern. On Greenhouse, it is yet another UUID in x-profile-key, different from the userid above. On other systems, it seems to be based on the user name.
4. subscriberId: The "lotuslive id" used by Connections cloud.

Can someone explain the relationship between snx:userid, key and subscriberId, on-prem and on the cloud, and what they are for? I can't find any clear documentation around it. The API doc says that some times we should pass the key, and some times the id.

Also is the LDAP directory on prem. We are querying the LDAP directory (WAS federated directory, also used by Connections) to get a list of users based on a group. But then, how can we access their Connections profiles from the LDAP result? Is their an attribute to read? We are currently using the email, but as said earlier, this will not work if email access in disabled, like in Greenhouse.

Answer 1

I can explain part of it. the snx:userid is an abstraction used to uniquely identify a person - even if their email changed, name changed, or any other ldap specific id changed. The snx:userid is I believe 64bit.

I thought the Key is the same as snx:userid.

SubscriberId is based on the Business Support Services long id, and includes a scope so that each environment has a unique id.

I think I described the first part of your question on the relationship.

For the second bit, we don't augment LDAP with the snx:userid.

You may want to look at User SPI and java.lang.String getExtID() http://www-10.lotus.com/ldd/lcwiki.nsf/xpAPIViewer.xsp?lookupName=IBM+Connections+5.0+API+Documentation#action=openDocument&res_title=User_SPI_ic50&content=apicontent

Answer 2

Hopefully this will help clear up some of the confusion and break down their relationships and uses.

snx:userid — This is actually not “generated” by Connections, but rather is associated with an LDAP attribute that is defined during the population process. Generally it is defaulted to an LDAP attribute that is and will always be unique to a user so that it can be used to identify a user in the LDAP if other content has changed. In some cases you’ll see this as the GUID of the LDAP (the default setting on-prem), though other times you’ll see this as a different value, like on the cloud for example. The cloud has this set this to the subscriberId.

subscriberId — This is generated and based on our Business Support Services as Paul mentioned. It is used as the true unique identified for a “subscriber” (user) to the environment, since the environment is MT and users need to be scoped. This was chosen over the default GUID as a unique identifier for a variety of logistical reasons.

key — This is generated by Connections itself during the population process. It is used to define the users profile within the context of Profiles and provides Connections with the ability to associate content with a user when the users LDAP information has been altered. It provides a separation of identity and helps facilitate user content synchronization for Connections.

Unfortunately there isn't a clear cut way to perform that lookup though, especially when you take something like Connections Cloud or Greenhouse into account. They have email disabled for a variety of security reasons. Generally speaking though, the userId is the GUID for the ldap, unless it is very explicitly redefined and configured so, but again you'd really have to know the environment in order to know that information. In a nutshell I think it has to be a configuration parameter for the app per environment if email is disabled.