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.

22

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