Collaborators at the Gates of Troy: Extending eServices at USC

1. Collaborators at the Gates of Troy: Extending eServices at USC

2. The Guest Problem • Institutions need to provide eServices to members • Who are members? The essential constituents: • Students • Faculty • Staff employees • Many non-members who also receive eServices: • Library patrons • Alumni • Recent students • Incoming faculty and staff • Emeriti and retirees • Visitors - Visiting scholars and researchers, summer programs, volunteer faculty, vendors, etc.

3. Legacy Ways to Provide eServices • “Force Square Peg into Round Hole” Method • Incomplete record of individual forced into a system of record such as the Student System or Payroll • Creates problems: • Mixes non-members into member populations • Undermines common assumptions • Student Record => Student ID => Student • Employee Record => Employee ID => Employee • Requires special activation/deactivation practices • May inappropriately provide/constrain service access

4. Legacy Ways to Provide eServices • “Manage Accounts not People” Method • Create accounts in electronic service systems • Gap between Identity System and Account store • Identity information stored in the Account store • Conflicts when the account holder becomes a member • Can result in privileges being given out for longer than needed • Difficult to determine all services accessible by the person • Gap between Identity System Policy and Account Practices • Application account administrator acts as policy maker in a policy vacuum

5. Examining Trends • More non-members requiring eServices • Common movement between member and non-member roles • Wider range of eServices that departments want to extend to non-members • More services becoming integrated with GDS for authentication, authorization, and personalization • Person Registry • Manages identities • Basis for populating the USC Enterprise Directory “GDS” • But how best to get non-members into the Person Registry?

6. Identifying and Managing Affiliates

7. USC Sponsored Guest System: iVIP • Requirements driven by a committee of academic and administrative leaders • Developed by Central IT resources in Identity Services Team • Integrated with Person Registry for Identity Resolution • Integrated with GDS for authorization to services • Web interface delegated to trained department administrators • Proposal for a new Office of Identity Management to take ownership

8. IAM/GDS Collaborative Committees • All committees are chaired by Margaret Harrington, the Director of the Office of Organization Improvement Services • Directory Steering Committee - management committee meets every 3 weeks • focuses on policy regarding data acquisition and release, integration, and communication • Attendees include senior management representatives from academic schools, administrative departments, IT Security Office, General Counsel • iVIP Steering Committee - management committee meets every other week • focuses on requirements of the iVIP system to allow services to be extended to non-members • Attendees include representatives from academic schools, administrative departments

9. iVIP Policies - Initial phase • Required attributes - Name (first and last), Date of Birth, and two forms of contact - email address, telephone number, or physical mail delivery address • All iVIP administrators must complete iVIP training • All granted iVIP services must have a start date (within a year) and an end date (within a year of start date) • One sponsoring department acts as primary sponsor for the VIP • Sponsor must be a benefits eligible USC employee and be identified by the department dean or Vice-President • VIPs are outside standard active lifecycle of Student and Employee Systems

10. iVIP Roles • Program Director • Primary Data Steward for Guest/Affiliate system • System Director • Technical manager of Guest/Affiliate System • Department Executive • Delegates authority to sponsors and lead administrator; typically a dean, chair, or vice president • Department Lead Administrator • Manages the sponsorship process for the department and assigns department administrators. Must be a full-time USC employee. Must complete iVIP training.

11. iVIP Roles • Department Sponsor • Faculty or staff member with authority to sponsor a guest/affiliate on behalf of a department • Department Administrator • Responsible for operational interface between sponsors and the Guest/Affiliate system. Enters requests into the iVIP system. Must be a full time USC employee. Must complete iVIP training. • Service Manager • Responsibility for a service such as Email, Blackboard, White Pages, Portal. May determine additional requirements for Guest/Affiliates requiring access to a service. Can remove a Guest/Affiliate from a service if need be. • Service Administrator • Administrator of a service. Has responsibilities regarding the accounts within a service.

12. iVIP Services • Any department can sponsor an iVIP for any services defined in iVIP • iVIP services: • University USCID • University Email • University white pages listing • University white pages lookup • University VPN • University Portal • Blackboard (2008)

13. iVIP System Information • Web App developed internally in Java • Accessible via common web browsers • Oracle database backend • Web app developed in 1 year by internal ITS senior Java developer assigned full-time • Modifications to back-end account system req 1 year • Functional requirements set by committee of academic and administrative representatives, chaired by Office of Organizational Improvement • Technical requirements determined by central ITS IdAM team and Identity Services Architect

14. Authorizing Access to Services

15. Authorization Model • Service Provider provides user population definition • based on attributes in the GDS provided by the SOR’s, or • as a discretionary (exception) group recorded in the GDS • GDS Authorization Group is used to record the application user population and assign an entitlement for the service • Shibboleth releases attributes to the Service Provider only for users with the entitlement value for the service

16. Authorization Model • Attributes released must be approved by the Directory Steering Committee via the AAR process • Authorization to use a service is determined at the Identity Provider based on GDS attributes BEFORE any attributes about the user are released to the service. • Service Provider and Identity Provider must both agree someone is authorized for access to the service

17. Supported eServices Cases • Member Access to an External Web Resource • Non-member Non-Federated Access to a USC Hosted Resource • Federated Access to a USC Hosted Web Resource • Federated Access to an External Resource Provider Associated with USC

18. Member Access to an External Web Resource • Accomplished via USC Member account and Shibboleth 1.3 • 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

19. Non-member Non-Federated Access to a USC Hosted Resource • Accomplished via iVIP and USC provided account • User is sponsored in iVIP which establishes a Person Registry entry and allows the assignment of USC services. • User is assigned a USC account and uses the USC First Login web page to establish a password for the account. • Examples: USC Email (Dec 2007), Blackboard (summer 2008)

20. Federated Access to a USC Hosted Web Resource • Accomplished via 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.

21. Federated Access to an External Resource Provider Associated with USC • Accomplished via 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 external services. USC assigned identifier is released to the service, not the home institution identifier.

23. 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. • 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. • Could be supported if USC decides that employees and students can approve the release of identity information held or assigned by USC about themselves

24. On the Near Horizon • Service integration added to iVIP effective Dec 1 • Blackboard Shibbolization, Spring 2008 • Conversion of Email guests to iVIP - ongoing through summer of 2008 • Expansion of user populations in SOR’s - Alumni, Emeriti, retirees • Expansion of services offered in iVIP, Summer 2008 • iVIP phase 2 - Fall 2008 - requirements tbd

25. USC Identity Management Team • 1 FTE Identity Services/Directory Architect • 1 FTE Developer focused on Person Registry • 1 FTE Technical Analyst focused on Shibboleth IdP and Metadirectory/Directory Services • 1 FTE Sr Java Application Developer • 2 FTE Legacy Account Management • Note: Server and Directory operations and support are managed by resources in another department. • Open Positions - 2 Developers, Web Services Architect

26. Links • Shibboleth website: http://shibboleth.internet2.edu • USC AuthX website: http://www.usc.edu/its/services/authx • USC GDS website: http://its.usc.edu/~bbellina/gds • Contact the author via email: bbellina@usc.edu

27. Questions