1 / 18

University of Michigan Enterprise Directory Services Appendix A Conceptual Architecture

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

nash-burks
Download Presentation

University of Michigan Enterprise Directory Services Appendix A Conceptual Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. University of MichiganEnterprise Directory Services Appendix AConceptual Architecture

  2. Architecture - Current

  3. Architecture - Current

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

  5. Dearborn Flint DAC MAIS Logic & Policy Directory Architecture - Future Institutional Data • Make All Institutional Directory Data Available Through One Interface • Centralized Policy • Live Data Flows • Isolates Databases

  6. Directory file Architecture - Future Provisioning Tool • Leveraging Directory Data to Make Local Provisioning Decisions • Per-Department • Directory & Service Connectors Reusable Local Logic print net

  7. Architecture – Future

  8. Architecture - Future

  9. 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 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

  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.

More Related