...
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?
You say "Potato" and I say B6BCC1F2-C25B-4273-8927-B769E73D8BE4
Different Cloud partners have different names for the same thing. Different partners have different meanings for the same word. There are different standards available.
What we normally call the Last Name (in the US) poses a problem because in China the family name comes first and then the given name. Some systems know this, while other systems are not so sophisticated. In different standards, this data field can be called the "sn", "surname", http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname, http://schemas.xmlsoap.org/claims/LastName, or "urn:oid:2.5.4.4".
Different partners have different limitations on the values allowed for certain identity fields. The number of allowable values for "sex" has become more complicated recently.
Mapping between an internal semantic system (a database) and an external semantic system (an XML schema) is an ongoing problem. Boundary IAM systems (like Shibboleth or ADFS) may have to adapt internal values to more restricted value systems required by a Cloud partner.