university of michigan enterprise directory services appendix a conceptual architecture
DESCRIPTION
University of Michigan Enterprise Directory Services Appendix A Conceptual Architecture. Architecture - Current. Architecture - Current. Name:. DoB:. Sex:. Etc:. Roles. UNS. UMID. Architecture - Future. ID Maker For Ad Hoc IDs Require Demographics Find/Assign UMID Assign Uniqname - PowerPoint PPT PresentationTRANSCRIPT
University of MichiganEnterprise Directory Services Appendix AConceptual Architecture
Architecture - Current
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
Dearborn Flint DAC MAIS
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
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
Logic
MAIS
Directory
Directory/DB
Connector
Provisionator
Service
Student
Web Server
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 emails 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
Logic
MAIS
DirectoryDirectory/DB
Connector
Provisionator
Service
Dept.
Teaching Assistant
Student
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 email 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 email account to the new professor.
• When the professor’s appointment begins, other campus services become available, such as cardkey access.
Logic
Sponsor DB
Directory
Administrator
New Professor
Directory/DB
Connector
Provisionator
Service
File Space Email
Dept.