Adventures in Identity Management Exploring Ethos Identity implementation

Adventures in Identity Management Exploring Ethos Identity implementation, benefits, and cautionary tales with Wilmington University Jeremy Watkins Wilmington University

Ellucian Implementation Timeframe • • • Contract signed: Feb, 2016 Implementation began: Apr, 2016 CRM Recruit applicant portal: Oct, 2016 Ethos Identity: Oct, 2016 Banner Admin: Jan, 2017 Banner Fin. Aid, SSB 8: Feb, 2017 AD Student account migration: Mar, 2017 Ellucian Share. Point e. Portal: Mar, 2017 Banner Student, SSB 9: May, 2017 Implementation “complete”: Oct, 2017

A busy 18 months!

Account Management Background • AD employee domain (staff, faculty): 2, 500 • AD student subdomain (applicants, students, alumni): 107, 000 • Various authentication methods, many disconnected accounts o ADFS o HR o Legacy SIS portal o Blackboard o Separate accounts by role • • Employee email via Exchange; Student email via custom Gmail Homebrew SSO, account provisioning tools No master identity system unique ID linking accounts No cleanup processes = many obsolete records

Our Journey: Decisions • Maintain multiple login accounts for staff/faculty vs student? o Multiple accounts very undesirable for Portal use o High level of effort and disruption to merge accounts • Maintain parent/child domain structure? o Networking/security considerations o Difficulty moving accounts between domains • Unified email services? o Email address format o SPAM filtering • Use Ellucian Active Directory adaptor or write our own? o Ellucian- Limited functionality but could be implemented quickly o WU- Highly extensible but large investment of time and effort

Our Journey: Migration • Cleanup obsolete applicant accounts: 27, 000 • Merge duplicate accounts (staff/faculty AND student): 1, 600 • Change student account format, email address, and domain jsmit 95467@wildcats. wilmu. edu -> jsmith 003@my. wilmu. edu • Move to new student email service Gmail -> Office 365 • Develop custom account migration process: 80, 000 records o 60+ hours continuous processing o 99. 997% processing accuracy o Manual cleanup of identified account issues • Generate UDC_ID records for all Banner persons: GOBUMAP • Populate UDC_ID data into custom AD attribute

Our Journey: Automation • Banner Events Publisher (BEP) o Custom Banner Roles: GORRSQL o Custom Banner DB Triggers: GORIROL, GORADID, SIBINST, SFRSTCR, etc • Banner Enterprise Identity Services (BEIS) • Custom SPML processor (C# application) o Evaluates output of BEIS message o Determines action needed (account exists or not) o Calls custom Active Directory Account Utility library o Initiates automated email communications for new accounts o Processes 500 -1000 updates per day • Active Directory account transitions o Ongoing account “promotion”/“demotion” processes being developed and enhanced

Account Management Workflow

Issues Encountered • *Identity matching issues -> duplicate Banner person records • Share. Point security: e. Portal unable to read roles from Ethos/AD o Ethos Identity not sending role membership upon Portal login o Child domain security groups required explicit mapping in Ethos o Share. Point Trusted Identity Provider misconfigured • • • CRM consoles: SSO via Ethos initially not available Mobile authentication complexity: UPN vs username Ethos clustering configuration -> periodic service failures (JVM) *Self-service password reset difficulties (personal email) *Two-factor unavailable

Realizing the Benefits • Very stable, highly extensible, industry standard solution (wso 2) • Extensive authentication integration o 50+ Service Providers (SAML 2 and CAS) o 16 Ellucian applications o 13 Internal/external applications (custom, vendor) o Custom endpoint redirection • Ethos Identity connected to AD parent/child domains via multiple domain controllers (load-balanced, high availability) • Automated account creation and maintenance via BEIS/SPML • Multi-phase account provisioning: Portal/login, email (enrolled) • UDC_ID linking accounts across critical systems • Coordinated account promotion/demotion processes (account transitions between staff/faculty and student domains)

Account Mgt: Ongoing Improvements • When is a student not a student? o When they are an employee or faculty member! • When is an employee not really an employee? o When they are a college work-study student • When is a faculty member no longer active? • Constituent status changes often require account transitions o Student -> Employee/faculty § Reformat username, email § Move to staff domain o Employee -> Student § Reformat username, email § Move to student domain § Disable admin systems accounts

“Everything is Connected to Everything” • Errant data updates in one system WILL cause significant downstream effects in multiple other systems o Mass data updates require intricate, coordinated efforts o “Cleanup in aisle 7!” • Extensive maintenance and upgrade validation o “Were you with your trigger all night? ” • Increasing institutional awareness of connected systems and account management consequences • Developing healthy partnerships o HR o Faculty Support o Financial Aid (work study) o Admissions o Communications teams