Columbia Identity/Access Management. (another tawdry tale of access control convergence)

Transcription

1 Columbia Identity/Access Management (another tawdry tale of access control convergence)

2 The Environment (2006) Highly decentralized and diverse university environment (so what else is new? ) Multiple campuses (a new one coming!) and affiliate institutions (Teachers College, Barnard College, Union Theological Seminary) Multiple access control systems Separate badging system A zillion card types (SSN on mag stripe!) Rather inconsistent deprovisioning

3 SIAC Project (1 year) Eliminated SSN on ID cards Unified multiple access systems (well, most anyway) with single OnGuard platform Integrated physical security and logical security Deployed HID iclass badges with contactless readers Deployed large amount of field hardware (now over 1400 readers and 2200 cameras) Upgraded IdM from Ingres to Oracle and rewrote core IdM Developed next-generation, homegrown provisioning tool ( DIA ) Facilitated/upgraded operations for Public Safety, University Housing, and 5 badging offices Integrated IdM with Blackboard transaction system

4 Identity Management Locally developed IdM system (Ingres Oracle database during SIAC, LDAP directory services) dating back to 90 s Logical provisioning waffil system (not realtime) Software components developed locally during SIAC project include idm2lenel interface and DIA (Delegated Identity Administration) provisioning tool

5 DIA (Delegated Identity Administration) DIA web-based provisioning allows departmental administrators to onboard employees and nonemployees (not students) with online and physical credentials in real-time Authorization for DIA administration tied to PeopleSoft personnel system privileges System of record data still provided in batch (student and employee systems, plus several affiliate institutions) netid ( UNI ) and cardholder/badge record created or modified

6 DIA

7 idm2lenel idm2lenel consumes events of interest (add/delete/modify within IdM) via Web service, and executes business logic which in turn produces calls to Lenel through dataconduit Biodem data, Lenel roles, badges, and access levels created/modified DIA-to-Lenel executes in near-time; particularly useful for ID centers that also provision (library and fitness center) Access deprovisioning in near-time for DIA transactions and overnight for batch data

8 Lenel Customizations Lenel customized to populate up to 3 campus roles per person based upon role hierarchy Roles determines badge type, deactivation date and default access levels Roles printed on back of badge UCN trigger randomly generates badge numbers

9 Roles

10 Access Levels

11 Problems Just a wee bit of stabilization for SIAC project (for a couple of years) dataconduit bug (deprovisioning); resolved instability of OnGuard linkage service; seems better now (fingers crossed) large queue of IdM events (from batch) can take long time to process by idm2lenel (dataconduit is slow) only most general access levels currently provisioned automatically

12 Roles and Responsibilities Infrastructure and application administration: CUIT TI and IAM Provisioning: systems of record, DIA users, some badging offices Field hardware support/deployment: Public Safety at Columbia, ACT (our VAR) at Teachers College Access issues: Public Safety Badging and card support: ID Centers IdM, idm2lenel, and everything but the kitchen sink: IAM

13 Next Steps (done) NEC HA deployed 2008 Idm2lenel interface total rewrite 2008 Online photo submission rolled out in 2009; allows new students to submit photos and ID Centers to approve for population in Lenel Comm server farm now consists of 7 VMs and growing, for video and edge readers Built out homegrown reporting infrastructure

14 Next Steps (soon-ish) Utilize more efficient dataconduit call to assign access levels (primary overhead per transaction) SOA? Provision finer-grain access levels Card number-to-person translator for users of wedge readers that track events and attendance More VM, more comm servers, blah, blah, blah