1 / 9

Campus Community Growing Pains at the Univ. of Wisconsin

Campus Community Growing Pains at the Univ. of Wisconsin. Common Solutions Group Duke University, 11-Jan-2001 Keith Hazelton, Univ. of Wisconsin http://www.wisc.edu/arch http://axle.doit.wisc.edu/~haz. Campus Community growing pains at the University of Wisconsin. Going multi-campus

olympia-baxter
Télécharger la présentation

Campus Community Growing Pains at the Univ. of Wisconsin

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. Campus Community Growing Pains at the Univ. of Wisconsin Common Solutions Group Duke University, 11-Jan-2001 Keith Hazelton, Univ. of Wisconsin http://www.wisc.edu/arch http://axle.doit.wisc.edu/~haz

  2. Campus Community growing painsat the University of Wisconsin • Going multi-campus • From ID office to…? • Going inter-institutional CSG, Duke University

  3. Going multi-campus • UW-Madison University Directory Service 2.0 • Registry with all People of Particular Interest ( PoPI ) • …and finally a production LDAP directory • UW System has asked us to implement a registry and LDAP directory for all 26 institutions CSG, Duke University

  4. Going multi-campus • A person in the UW System registry may carry one or more roles at one or more campuses • Are there service distinctions? • What assumptions and systems will this break? CSG, Duke University

  5. From ID office to … ? • Personnel has told us that our PAM* can’t take on any more work • The class of “others” in the registry is growing • Some of us think we now need a true Registration Authority • That’s a big step * Post-algorithmic Mechanism CSG, Duke University

  6. …A Registration Authority • A function (probably distributed) that would • Perform the bootstrap identification and authentication process • Issue a credential of some sort CSG, Duke University

  7. …A Registration Authority • People would often be in the registry before they were sent to the RA • SAT test score files, sales reps • Only when a person becomes “of particular interest” do they get sent to the RA • Where is the line? Applicants? Visiting researchers? CSG, Duke University

  8. Going inter-institutional • eduPersonAffiliation attribute • In the eduPerson object class 1.0 (22-Jan-2001) • Controlled vocabulary • Involves radical simplification • Faculty, staff, student, alum, member, affiliate, employee • “Member” is any one or more of fac/staff/student/employee • “Member” is the most generic service class (parallels UW-Madison “eligible for ID card”) • Will evolve by the eduPerson community process 1.0 CSG, Duke University

  9. Going inter-institutional • Paired with PKI, would find application with the computational Grid (ANL, Condor, etc.) • They would prefer institutionally-issued certs to their current homegrown approach • Would support inter-institutional collaborative workgroups and open access to distributed computational resources CSG, Duke University

More Related