When IIQ Birthright Email Provisioning was written there was a long sequence of tests and steps that were required. Over the last five years, however, some of the tests have been relaxed and some processing has been moved elsewhere.
The Identity Management IIQ (which shares Java code with Email Provisioning) now calls some of the code written for Email Provisioning when it assigns a new Netid. Specifically, it creates an AD User object and it reserves an Email Alias.
The Azure AD Connector (“directory synchronization”) process now assigns required information in new Azure AD objects that were previously ignored.
Licenses are now assigned by “group-based provisioning” managed by Grouper.
Email Provisioning IIQ now has to update Email routing fields of AD, so it now aggregates identity data with affiliations MEMBER and AFFILIATE in addition to the previous affiliations entitled to Brighright mail (STUDENT, FACULTY, STAFF, and EMPLOYEE).
After these changes, the Email Provisioning instance of IIQ can be easily changed to assign O365 Email to selected SIs and Academic Affiliates based on setting some flag in a database or directory.
Changes
The 5:30 AM Job
This job aggregates IDRIdentitiesView, the LocalAD, and the Email aliases in StagingDB. Today the IDRIdentitiesView selects all identities whose PrimaryAffiliation is not NULL or ALUM, so SIs and Affiliates are now included.
It then runs the “Netid” Role Selector Rule against all Identities. The initial statements in the Rule are written to quickly reject anyone who is not entitled to Birthright Email (by Affiliation), who is already in the middle of Birthright processing (have a non-NULL MailStatus), or who has an Email account.
The Identities who are not rejected begin Birthright Email processing. However, the two important steps performed at this time (reserve a primary Email Alias and create an AD User object) today have already been preformed by the Identity Management IIQ in a similar Netid Role that was subsequently added to it.
This Rule needs to be changed so it does not reject someone with Affiliation of MEMBER or ASSOCIATE when some flag is set indicating this Identity requires special processing. Whatever code sets this flag also has to reset the MailStatus to NULL