Inherent Inconsistency
Because Identities at Yale are driven by data sources (HR, Banner, Darcy) that are not under the control of IAM, and each of these sources has its own DEV, TEST, and PROD environments, IAM systems cannot be said to have a clear strategy for identity information. Rather, we receive the results of testing from HR, Registrar, and Alumni activity and have to adapt to that input.
IAM maintains its own set of DEV, TEST, and PROD systems and database tables. While some of the information in our systems comes from the original authoritative sources, other data is the result of manual steps to define, activate, or provision entities in the DEV and TEST environment using the same tools that manage production identities.
However, the DBAs periodically "refresh" TEST and DEV databases from the original PROD sources. When this occurs, if it involves an IAM table managed by IAM tools, then the effect is to replace the history of DEV or TEST manual provisioning with a copy of the manual provisioning in production. This is necessary because certain key elements of identity (Netid and UPI for example) are dynamically generated by IAM systems running independently in DEV, TEST, and PROD and they may assign different values to the same person in the three environments. So the periodic refresh of PROD data to DEV and TEST creates uniformity for at least those people who have been at Yale for more than 9 months. After a refresh the key identity items (Netid, UPI, First, Last, Email) will end up consistent across all the IAM tables and systems, but secondary test accounts and provisioned data items may be inconsistent. In some cases they have to be consistent with PROD anyway.
Meanwhile, an increasing number of application systems that rely on IAM data are commercial products with their own assumptions and they may or may not have TEST instances, and even if they have application-test instances those systems may not be connected to our TEST environment. Generally speaking, when the application test instance is created, the application administrator (someone not related to IAM) decides to configure the SSO of that application and may, at that time, choose to associate his test instance with https://auth.yale.edu/idp or https://auth-test.yale.edu/ipd and that implicitly decides whether he gets PROD or TEST data.
Yale maintains three instances of Active Directory (yale.edu, yale.net, and yale.org) but unlike databases there is no "refresh" of data (particularly passwords) from PROD to TEST or DEV. The IAM systems running in the TEST and DEV environment will notice identities created in the IAM databases and, as a result, they will create AD User object in yale.net and yale.org, but because these objects have no password they will be locked until someone uses DEV and TEST IIQ to issue a PIN and then uses DEV and TEST Netid to assign a password.
Limitations on Duplication
The only way we could have a completely consistent separation of DEV, TEST, and PROD would be for everyone involved in testing to have three laptop computers and maybe three cell phones. Since that is not reasonable, what generally happens is that core identity functions are made consistent, but that means that peripheral identity functions are left to manual intervention.
Consider the question of E-Mail. This is an important question because eventually E-Mail will be provisioned out of IIQ, but right now it is managed by a loose set of peripheral systems.
The three Eliapps mail systems are bulldogs.yale.edu (prod), bulldogs.gtst.yale.edu (test), and bulldogs.gdev.yale.edu (dev). Let us start by pointing out they are cloud partner provided systems labelled dev, test, and prod by the Yale service owners of that family of services. Any relationship they may have to IAM DEV, TEST, and PROD systems is something that IAM has to code. Because only a very small number of people at Yale need test E-Mail accounts, Yale would be foolish to automatically provision a bulldogs.gtst or bulldogs.gdev mailbox for everyone who automatically qualified for a production mailbox. This means, however, that either DEV and TEST mailboxes must always be provisioned manually or any autoprovisioning logic (in a future IIQ) would have to be limited to a small subset of the users who would qualify for accounts using the production logic. Currently you get a bulldogs.gtst.yale.edu mailbox only by manually creating one with the TEST Improv utility.
Since there are three ADs (yale.edu, yale.net, and yale.org) there are also three Exchange servers. However, the binding of Exchange to AD means that there are rules on the E-Mail address imposed by the AD naming. Potentially there could be accounts for john.doe@yale.edu, john.doe@yale.net, and john.doe@yale.org. These names are enforced for mail sent from one Exchange account to another (when john.doe@yale.net sends mail to mary.smith@yale.net).
Separately there is the question of Mail Aliases. There is a non-unified mechanism for user requests but in the long run this feeds network infrastructure called the "mail relays" where a single set of boxes resolves aliases into native mailbox addresses based on what is mostly production input from the ACS1 version of the DIR_ONLINE_INFO IAM table, but with some manual configuration. For example, there is a generic rule that first.last@yale.net will always be resolved to first.last@connect.yale.net which is good enough for Exchange testing but automatically means that nothing in the TEST environment can duplicate the service that, in production, first.yale@yale.edu can either be mapped to Exchange or Eliapps on an individual case by case basis.
There are no plans to create DEV and TEST mail relays.
There are no plans to resolve a yale.net alias to a bulldogs.gtst.yale.edu account.
Because DIR_ONLINE_INFO is refreshed periodically from ACS1 to ACS2 and ACS3, there is no place to store dev or test aliases long term.
Yet when TEST IIQ starts to provision E-Mail addresses, these limitations will have to be rethought.
Synchronization
Currently DEV, TEST, and PROD make some decisions independently and then they are synchronized after 9 to 12 months when the production databases are copied to dev and test. The current generation of IAM tools has no logic to reconcile the three environments more quickly. Because AD cannot be replicated, the passwords have to be managed separately in the three systems although there are unsactioned tools not managed by IAM that allow passwords to be synchronized between yale.edu, yale.net, and yale.org in a more user friendly manner.
Should basic IAM data (netids, UPI, email address) be synchronized between these environments more frequently?