Identity and Security Management at Duke University

Session ID: T-1

Agenda

About Duke University

Identity Management Challenges

Identity Management System Components

Administrative Systems Challenges

Administrative Systems Components

Business Process Example

Key Development Objects

Questions

About Duke University

University and Health System

14,950 undergraduate and graduate students

36,000 employees

$5.4 billion operating budget

Three hospitals in Durham and Raleigh

Clinics in North Carolina and Virginia

Identity Management Challenges

Variety of identity types

Numerous systems/services

Multiple physical locations

Decentralized management

Identity Management Challenges

•Employees•Students•Patients•Contractors•Affiliates•Alumni•Donors•Volunteers•Media •Visitors•Parents•Doctors•Residents

•Campers•Temporary staff•Visiting professors•Weekend MBA’s•Corporate education•Temporary staff

Identity types and provisioned services - examples

•Email •Email groups•Class rosters•Class materials•Computing resources•Network•Filesystems•Applications•Streaming media•Building access•Room access•Sporting events•Other special events

Identity Management ChallengesCampuses, hospitals and clinics in North Carolina and Virginia

Identity Management Challenges

Decentralized management

Two separate central IT departments, University and Health System

Many local IT departments in various schools, departments, etc.

IDM System Components

Oracle IDM 9.1

MIT Kerberos5 12.2

Shibboleth 3.1.2

Duke Unique ID

Microsoft Active Directory 2008r2/2012r2

Grouper 2.1.5

SUN LDAP 6.3 (changing to 389 DS)

IDMS Architecture

Administrative Systems Challenges Large number of users

High turnover

Complex authorization requirements

Multiple applications

Need a single point of entry for maintenance

Administrative Systems Components SAP ECC 6.0 SAP BW 7.3 & BI Java SAP Enterprise Portal SAP BO Enterprise SAP CRM 7.0 SAP SRM 7.0 SAP PI 7.0 Kofax (scanning, fax) Mobius (content repository) IBM Brass Ring (candidate selection) ECRT (effort certification) API (Time & Attendance)

Administrative Systems / IDMS Architecture

Hire Process Overview Position requisition created/approved in MSS

Open position posted in Candidate Selection

Candidate selected, data transferred to MSS hire form

Identity created/verified

Hire approved, personnel record created

Identity updated with organizational attributes

Administrative systems accounts provisioned

Roles updated in administrative systems

IDMS is continuously updated with ECC organizational data

Roles, services, applications, access, etc. move as a person changes positions or leaves the organization

ESS, MSS applications change data that propagates through the Administrative, IDMS systems

MSS: Name, Campus address, faculty appointments, titles, job transfers

ESS: Home address, telephone, etc.

Active Directory information synchronized with Health System AD for separate purposes (HIPAA, clinical applications, etc.)

IDMS-initiated changes are replicated in Administrative Systems

Email aliases

Copied and modified RHPROFL0 to update roles in all ABAP systems based on naming convention and position/user assignment

Built a portal component to perform UME actions (see http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/3052)

ABAP program to build portal user/group assignments and call UME component above

ABAP program to extract role data and transmit xml update files to ECRT, Brass Ring

ABAP call to stored procedure in Duke UniqueID database to verify/create external pernr

Extract of people and organizational master data for daily interface to IDMS

Import of daily IDMS data into ECC

Web service called by OIM for organizational hierarchy information

Custom webdynpro application for ongoing departmental maintenance

Key development objects

Questions?