Person Directory Service to UW Windows Infrastructure Data Mapping

This document is intended for IT Professionals seeking to understand how data in PDS is mapped to UWWI.

Background

ILM is one of two UWWI components which can set directory information on NETID user accounts. This document only covers ILM behavior. The UWWI Kiwi component also sets some directory information, upon Kiwi events. The reader should consult the UWWI Kiwi documentation to be aware of changes which might intersect with what is represented here.

Table Legend

The following table shows which PDS attributes are connected to which UWWI attributes. However, this table doesn't tell the full story. In most cases, a direct mapping is involved, meaning that the PDS attribute value is unchanged and set on the UWWI attribute. The direct mappings are colored blue. However, this is not true of all cases. For the cases where it is not true, a more complicated algorithm is used to determine the UWWI value based on input from the PDS value(s). The more complex mappings are colored purple, and explained below.

Publishing Flag and Multiple Affiliations

In almost every case, you'll see that a PDS attribute with "publish" in the name is present. These "publish" attributes are sometimes called publishing flags. They govern whether the individual has allowed a set of information about them to be published. If the individual has chosen to allow publishing, then UWWI makes use of that information. However, in some cases it's more complicated, because there are multiple publishing flags and potentially several sets of personal data depending on the affiliation of the person. In the case where a person is both staff and student, the staff personal information is preferred. If only one of the two flags permits publishing, then only that set of information is used.

Complex Attribute Mappings

For both naming attributes and the email address attribute, a more complicated algorithm is used to determine the UWWI value based on input from the PDS value(s). As noted above, the more complex mappings are colored purple in the mapping table above.

Name Attributes

“Name Attributes” for the purposes of this discussion:

• givenName
• initials
• sn
• displayName

Name Sources

There are three possible sources for name information (in descending order of priority):

• uwEWPName
• uwSWPName
• uwPersonRegisteredName
  • uwPersonRegisteredFirstMiddle
  • uwPersonRegisteredSurname

The first two sources are preferred as they represent the names of individuals as supplied by those individuals, and thus are more likely to contain correct casing, preferred names and other details that may not be as accurate in the values stored in the uwPersonRegistered attributes.

The availability of each of the name attributes is dependent both on the affiliation of the person with UW (e.g. only students have uwSWPName values), and whether the corresponding publish flag is set (uwEWPPublish and uwSWPPublish). If a person has not elected to have their information available in one of the information sets (Employee or Student) then the corresponding attribute will be treated as not available.

Names for Unpublished Persons

If a person has elected to not publish any white pages information then the name attributes will be set as follows:

• givenName = First Character in uwPersonRegisteredName + “.” ·        
• initials = blank
• sn = uwPersonregisteredSurname           First character to uppercase, remaining to lower
• displayName = givenName + “ “ + sn

Names for Published Persons

If a person has at least one of the publish flags set then their name attributes will be set as follows:

1. A “Name” value will be chosen by selecting the from the three name attributes in order of priority and subject to the appropriate publishing flag being set.
2. The Name attribute will be parsed. Each name attribute may be formatted as either:
   1. “Last Name, First Name Middle Name” or
   2. “First Name Middle Name Last Name”
      
      If a comma is present, then the first form (a) is assumed. Otherwise the second form (b) is assumed. The surname is then extracted from the Name attribute as the first part of the first form, or the last part of the last form. This may result in incorrect values for surname if the surname is composed of multiple parts separated by spaces. To mitigate this, if the second form is encountered, the last part of the name is compared to the uwPersonRegisteredSurname and if they match (case insensitive) then that portion of the name is deemed the sn.
      
      After parsing the sn value, the remaining portion of the name is parsed for givenName and initials. The first portion of the remainder is assumed to be the givenName, and the first character of the remainder is assumed to be the middle initial.
3. The displayName will be set as givenName + “ “ +  (initials + “. ”) + sn

Note that multipart first names (e.g. Mary Anne) will be parsed incorrectly under this scheme. Also note that additional unexpected text can cause incorrect parsing (e.g. Joe Johnson Jr.).

A Word About UWWI Naming Design

You'll note that the "published" name was chosen as the preferred information source over the registered name or some better value. You'll also note that we've chosen to "normalize" the naming data so there is consistency across the naming attributes.

There are differing opinions about these choices, but these choices result in allowing the end user the greatest amount of flexibility to directly influence their resulting name in UWWI. There are many problems with this choice, but the largest number of problems fall into one of two sets of conditions:

1. UW NetID is not a personal UW NetID, and so doesn't have user-editable naming information in any of the source attributes, nor does ILM join the PDS object with the UWWI object.
2. There is no syntax or formatting enforcement for the source data, which means we must make best guesses on how to correctly parse data which can be formatted an infinite number of ways.

With b) the choice of data input can be changed, and user education can help avoid problems. However, with a) there is no good workaround.

This design decision could be revisited in the future, however, there are a number of issues which must be successfully addressed or some user segment will be adversely affected, and changes to this design would be very user-visible.

Mail Attribute

The "Email Attribute" for the purposes of the following discussion is:

• mail

Email Sources

There are two possible sources of email address information (in descending order of priority):

• uwEWPEmail1
• uwSWPEmail

Email Synchronization Behavior

The ILM logic synchronizes the "published" email address info in PDS directly with no modification to the value, but only if that user does not have an Exchange mailbox.

If the user has an Exchange mailbox, it does not synchronize the PDS data to UWWI for the mail attribute. This is because Exchange links some of it's basic functionality to the mail attribute. The mail attribute must agree with another Exchange-centric attribute or else there will be Exchange problems for that user. Since the "published" email address has no logic validation upon which we might restrict user choices to agree with Exchange, once a user gets an Exchange mailbox, we must stop paying attention to the published email address for that user. Currently, this means that Exchange users must ask us to manually modify their email address if they desire a change. In the future, we may have a solution for this.

Also note that some UW NetIDs have no published email address for a variety of possible reasons. In that case, the kiwi account creation code covers this case by setting <uwnetid>@u.washington.edu. Currently, there's no way for those UW NetIDs to change their email address.

A Word About UWWI Email Design

You'll note that the "published" email address was chosen as the information source instead of the "UW forwarding" address or the general assumption of <uwnetid>@u.washington.edu. The UW forwarding service takes email destined for <uwnetid>@u.washington.edu and forwards it to a location of the user's choice. This choice is exposed at https://uwnetid.washington.edu/manage/?forward. This is in contrast to the published email address which for employees is exposed at https://prp.admin.washington.edu/ess/uwnetid/address.aspx (within the Campus Address section choose to edit the Email field).

There are differing opinions about this choice, but when all is said and done, using the published email address permits the widest amount of flexibility--which is why it was chosen. Obviously there are potential problems with this choice, including the possibility of bad data (not true with <uwnetid@u.washington.edu>) and the possibility that the value is not actually the address the user is actively using, but the rationale behind the choice is good. Bad data or choices can be refined, and user education should improve to help avoid them.

This design decision could be revisited in the future, however, there are a number of issues which must be successfully addressed or some user segment will be adversely affected.