University of Michigan Enterprise Directory Services Appendix A Conceptual Architecture

Architecture - Current

Architecture - Future ID Maker For Ad Hoc IDs Require Demographics Find/Assign UMID Assign Uniqname Departmental Roles Name: DoB: Sex: UMID UNS Roles Etc:

Architecture - Future Institutional Data Make All Institutional Directory Data Available Through One Interface Centralized Policy Live Data Flows Isolates Databases DearbornFlintDACMAIS Logic & Policy Directory

Architecture - Future Provisioning Tool Leveraging Directory Data to Make Local Provisioning Decisions Per-Department Directory & Service Connectors Reusable Directory Local Logic file netprint

Architecture – Future

Architecture - Future

10 Case Studies Scenario # 1: A math student needs to view her course web site to download class notes and assignments. The site should only be accessible to those currently taking the class.

11 Case Studies Scenario # 1 – What would happen today? Students add/drop via Wolverine Access Authorized person obtains class roster from MAIS via Wolverine Access Multiple class sections require multiple queries Class members are copied into a text file Web page ACLs are handled via.htaccess files, PTS groups, or equivalent ACLs become out of date as students add/drop Add/drop information doesn’t propagate in real-time The whole process must repeat each semester

12 Case Studies Scenario #1 - Future Student authenticates Web server examines ACLs on requested page Web server looks up user’s roles in Directory MAIS has already populated directory with roles indicating student’s participation in class Web page is sent to student

13 Case Studies Scenario # 2 A professor in the Aerospace Engineering Department wishes to allow students in his course to collaborate on group projects using shared file space. His class has one section, divided into four teams.

14 Case Studies Scenario # 2 – Current Environment Students add/drop via Wolverine Access TA obtains then-current class roster via Wolverine Access TA pastes the list of uniqnames into a text file TA randomizes the students into 4 groups TA s the groups, members, and other details to CAEN CAEN converts the user list into a format recognized by its account management scripts CAEN allocates course file space for each group CAEN creates AFS PTS groups for each team, assigns quotas and permissions accordingly Each time a student adds or drops the class, the TA sends additional requests to CAEN Any user without a CAEN account cannot obtain file space Updates of adds/drops do not happen in real-time At the end of the semester, CAEN takes the course space off-line This process repeats each semester, in a similar fashion, for many classes

15 Case Studies Case Scenario 2: In The Future? Student enrolls; data is stored at MAIS Central directory stores role information Central directory passes role information to end users and provisionators Provisionator fetches updates whenever they occur Teaching assistant or technical support utilize APIs to write a program that interacts with the provisionator that populates groups automatically each semester

16 Case Studies Scenario #3 A new faculty member has been hired; however, the appointment won’t be effective for three months. The department would like the individual to have and account access immediately.

17 Case Studies Case Scenario 3: What Would Typically Happen Today A uniqname may or may not be created; if a uniqname is created, it may not be created using University-recognized key(s) Must obtain either SINOA or SSN to allocate uniqname Departments provision resources locally without storing the individual’s information in any central database or directory Identity duplication can result

18 Case Studies Case Scenario 3: In The Future? Administrator collects sufficient amount of data to uniquely identify new faculty member and enters it into the Sponsor System Provisionator discovers the new entry and provisions file space and an account to the new professor. When the professor’s appointment begins, other campus services become available, such as cardkey access.