Identify and update email addresses in third party applications



Project is 40% complete, starting on Mon 4/3/23 and ending on Fri 1/5/24.

In Process [In Process]

40% complete, updated on Wed 8/2/23 1:18 PM by Craig Bentley

Greg & Co working on Disposition accounts


Mon 4/3/23 - Fri 1/5/24
Enterprise Applications
Project Requests / Information Technology Project Request
IT Projects / DoIT Project
Green - On track
Thu 1/12/23 8:14 AM
Mon 10/2/23 4:53 PM

Project Details

Divisional VP Support
Does your divisional VP support this request?


There are many third-party applications that authenticate via the campus Shibboleth authentication platform. As part of that authentication, some of those applications are sent an LDAP attribute called 'mail' that contains an email address. This address uses either the domain or the domain, depending on logic in Account Center that tries to determine the correct primary affiliation (employees get and students get Applications use this attribute to identify the email address for the user, but some applications also use this attribute to determine the primary identifier (username) for that user.

This project is to migrate all applications to use an attribute that provides an email address with the domain as part of our efforts to remove the domain from our applications.

Proposed milestones:
- Create a new attribute in OpenLDAP called 'email' (or whatever is decided). Use Account Center to populate that attribute with the email address for all accounts.
- Using the Shibboleth configuration files to create a list of applications that are currently being sent the existing 'mail' attribute. Identify owners and technical contacts for each of these applications.
- Work with each application owner to migrate their application to the new 'email' attribute. There are three possible situations that may need to be dealt with as part of this process:
- - The application does not rely on the 'mail' attribute as the primary identifier. This means that using the different attribute will simply update the email address of the application's user record. This is the easiest option.
- - The application relies on the email address as the primary identifier. Using the different attribute will result in a duplicate account getting created, but for this particular application there is no harm in that (since there's no history associated with the account). Updating the attribute will require a clean up effort to remove the old accounts, but should otherwise have minimal impact.
- - The application relies on the email address as the primary identifier and it is important to retain the existing accounts as they are so that user data is not lost. For these applications, we will need to coordinate with the vendor to develop a process for updating the usernames to the domain at the same time that we switch to the new attribute. This will ensure that existing user data is retained.
- Once all applications that use the existing 'mail' attribute have been migrated to the new 'email' attribute, that attribute can be removed and this project will be complete.

Note: the learning management ecosystem will be a challenging component of this migration, since all applications that are integrated with either Canvas or Blackboard will need to be updated at the same time to avoid losing user data. It may be a good idea to wait to do this part until after Blackboard is no longer in use, but this may also hold up other post-migration projects so it may not be possible.


Alternate Manager(s)