Joanne Berg, Registrar, UW-Madison Dan Edlebeck, Registrar, UW-Whitewater WACRAO Meeting

1. Joanne Berg, Registrar, UW-Madison Dan Edlebeck, Registrar, UW-Whitewater WACRAO Meeting November 4, 2004 IAA Overview

2. Presentation overview • Identity management overview • What is IAA? • How does it work? • What student data is used? • How is the data used? • History and Governance • Guidelines for Use

3. Identity management Identification & Authentication • Is the person wanting to use the service who she claims to be? • Is she a member of our campus? Authorization • Is she permitted to use the service? • Is her privacy being protected?

4. What is IAA? • An identity management system for UW System • Centralized identity management- reduces complexity, cost, and processing for applications • It aggregates information about student, faculty, staff and “other” populations from UW system-wide repositories to enable applications like Learn@UW and APBS • 330,000 individuals in IAA with one common identifier

5. Some key points about IAA • It’s efficient and user-friendly • We don’t need to worry about multiple usernames and passwords • IAA supports local campus policies and identity management mechanisms • Data ownership and policy decisions stay at individual campuses • It’s not a system-wide data warehouse

6. How it works… • Data is fed from the campus to the IAA registry • The IAA registry is used for: • User authentication and authorization • UW System White Pages Directory • Passwords are maintained at the campus, not in IAA.

7. Name Gender Birth Date Social Security Number ISO Number Deceased Indicator Source Key Value Email (official & preferred) Phone (home & cellular) Address (permanent & current) Username Institution Code Academic Calendar Term Student Status (Eligible to enroll, Enrolled, Withdrawn) Status Begin Date Status End Date Status Last Updated Full/Part Time Indicator Major Student Classification/Level (Fresh, Soph, Jun, Sen, Grad, Other) College Privacy Flag (yes/no) What student data is fed to IAA? Who determined these data elements were necessary? Lay-person description of these two elements

8. Common System Applications using IAA Authentication Hub Desire to Learn (Learn@UW) Kronos Hyperion APBS DSpace (Minds@UW) Student Appt & Payroll Payroll IAA Registry Data Relevant data System Campuses IAA White Pages passwords

9. First, we start with a user. This person is a community member at a UW Campus.

10. This person would like to access a Common Systems application that’s hosted by UW System

11. The person has a campus username and password, but the Common Systems application has no knowledge of it. It requires another identifier, known as the user’s IADS PersonID, which is generated by IAA.

12. The user’s home campus has a central authentication infrastructure (most likely LDAP) that allows applications to authenticate against a common directory.

13. That campus central directory service, along with the local Student Information System (and possibly other local systems) are feeding person data into the IAA Registry. This includes usernames, but does not include passwords.

14. The IAA Registry also collects information about employees through UW Processing Center. This feed does not include usernames for employees, however. They must come from each campus through the IAA Supplemental Data feed.

15. To bridge the gap between the person and the application, the IAA Registry is used in conjunction with the IAA Authentication Hub.

16. The user may access the application by authenticating through the IAA Authentication Hub login page.

17. If this route is chosen, the user must supply two additional pieces of information – their home campus and the application they’re attempting to access.

18. The IAA Auth Hub also allows for a campus portal to authenticate the user. In this mode, the IAA Auth Hub will trust the portal’s authentication. The IAA Auth Hub will then collect username, campus, and application.

19. If authentication is required, the IAA Auth Hub will contact the campus authentication server and will validate the username and password it was given.

20. The IAA Auth Hub will then use the IAA Registry to convert the person’s campus username to an identifier that the application will understand, that is, the IADS PersonID).

21. The IAA Auth Hub then redirects the user’s browser to the application, referencing a session number that the application can use to confirm that the user has authenticated, and conveying the user’s application-specific identifier (in this case the IADS PersonID) to the application.

22. The person has been authenticated to a Common Systems application using a campus username. The person did not need to know their IAA generated IADS PersonID, and the application did not need to know anything about the person’s campus username.

23. This all sounds reallycomplicated. What do I needto know?

24. A brief scenario… Password Verification comes from campus Bob enters ID and Password to access a system application that uses IAA authentication Bob is allowed “in”… Who Says Bob Is Allowed Into this application?

25. Who Says….? • The campus, based on the data submitted to the IAA registry. • An application sponsor requested use of IAA data to authenticate users and the IAA Governance Work Group approved the request. • The campus LDAP and the IAA Authentication Hub working together to authenticate and authorize Bob for the services/application.

26. Is there public access to IAA data? The White Pages Directory will be open to the public* • * FERPA protected Other than the White Pages Directory, no one SEEs, nor can they query IAA data

27. White Pages DirectoryAccess Instructions • Ask the Work Group … should we include instructions for accessing the White Pages if the WP are not available yet? • Should we demo the steps real-time ?

28. White Pages Directory example

29. IAA Governance Work Group(est. December 2003) Carrie Regenstein (UW Madison, Chair) Chris Ashley (UW System, ex-officio) Joanne Berg (UW Madison) David Crass (UW Milwaukee) Dan Edlebeck (UW Whitewater) Mary Fischer (UW Green Bay) Elliot Garb (UW Oshkosh) David Prucha (UW Extension)

30. IAA Governance Work Group Charge from Ed Meachen, UW System: • Ensure proper stewardship of IAA registry data (including security and privacy) • Make recommendations on the IAA registry and directory structures and any proposed enhancements or modifications to those structures • Make decisions on electronic or other applications desiring access to IAA services

31. IAA Guidelines for UseDeveloped by IAA Work Group • IAA data will only be used for purposes of providing identity management, which includes directory authentication and authorization services. • Compliance with State and Federal laws regarding privacy and security, eg. FERPA, and University policy. • Memorandums of Understanding (MoUs) between UWSA and entities submitting data to IAA. • The entity submitting data to the IAA registry will maintain the role of custodian of that data.

32. IAA Guidelines for Use • UWSA is responsible for maintaining and protecting the integrity and security of data submitted by participating entities while such data is maintained in the IAA system. • All access to IAA data must be approved by the IAA Governance Working Group. • Addition of data elements must be approved by IAA Governance Working Group.

33. Resources • IAA working group members • IAA website http://www.uwsa.edu/olit/iaa/ • IAA whitepages Whitepages.wisconsin.edu Should we include the URL for the White Pages ???

34. Questions