Opportunities and Efficiencies: Supporting Student Services with Federated Identity

1. Opportunities and Efficiencies: Supporting Student Services with Federated Identity EDUCAUSE October 31, 2008 9:30 AM- 10:20 AM Room W314A

2. What is the need? Identification and authentication for student and faculty needed for: -Access to role-restricted services within the university e.g., Instructor access to class rosters -Access to role-restricted services for USC users to external services e.g., Student access to iTunes U -Access to role-restricted USC services by external users e.g., Cross enrolled UCLA student to USC Blackboard course

3. MyUSC Portal

4. Login to MyUSC Portal

5. Single-Sign On Quick Links

6. OASIS On-line Access to the Student Information System

7. iTunes U an external service

8. External Web Service Models • One-Way Trust Model -Requires separate arrangement between USC and provider • Federated Model -Standards compliant predefined trust relationship and no separate arrangement

9. One-Way Trust Model USC Users Services WhatsamatterU Users Services iTunes U Service

10. Federated Model USC Users Services WhatsamatterU Users Services Federation iTunes U Service

11. USC is a member of the InCommon Federation • <http://www.incommonfederation.org> • USC uses standards-compliant Shibboleth architecture to provide access to web-based electronic services, both internal and external • <http://shibboleth.internet2.edu/> • USC has both one-way trust relationships with vendors and involvement in the federation • Currently only Shibboleth Wiki service relies on InCommon

12. Policies for USC Access to Services • Service must be sponsored by University leader • Service Provider must explicitly define user population • based on attributes in the GDS provided by the SOR’s, or • as a discretionary (exception) group recorded in the GDS • Service Provider must define required user attributes • Attribute release must be approved by Data Stewards and Directory Steering Committee • Shibboleth releases attributes for authorized users at service login.

13. eServices Cases: Member Access to an External Web Resource • Accomplished via USC Member account and Shibboleth 2.0 • User authenticates locally and Shibboleth IdP releases entitlement + attributes to external Service Provider if person is authorized • Examples: • Library Proxy Server • iTunes U • Shibboleth Wiki

14. eServices Cases: [Proposal]Federated User Access to a USC Web Resource • Accomplished via USC Guest/Affiliate System (“iVIP”) and Shibboleth and InCommon Federation • User is sponsored in iVIP which establishes a Person Registry entry and allows the assignment of USC services. • User uses the USC First Login web page to establish a link between their home institution account and the USC iVIP account. • User authenticates at home institution but is authorized by USC IdP to access USC services. USC assigned identifier is provided to the USC service, not the home institution identifier.

15. Case not supported: Open-ended Collaboration • Faculty member at external institution wants to grant access to his hosted service for USC faculty or students and is unwilling or unable to determine or communicate specific user population. • Not supported because it is in conflict with the USC policy of releasing identity information only when necessary. • Could be supported in the future for employees who have specifically not requested DNR. Unlikely to be supported for students due to FERPA concerns.

16. Additional Resources • USC GDS website: http://www.usc.edu/gds • Acknowledgment • Assistance from Brendan Bellina, Identity Services Architect, Information Technology Services, Univ. of Southern Calif. was essential. • Contact Information • Kenneth L. Servis Dean of Academic Records and Registrar University of Southern California serviske@usc.edu