IDENTITY MANAGEMENT ROLLOUT: IN A HURRY. Jason Blackader, UNIX Systems Administrator

Transcription

1 IDENTITY MANAGEMENT ROLLOUT: IN A HURRY Jason Blackader, UNIX Systems Administrator

2 Undergraduate, Graduate, Continuing Ed Industrial Design, Communication Design, Design Sciences, Arts & Media Two Campuses 1500 Degree Students, 3000 Continuing Ed 450 Faculty, 250 Staff

3

4 2007 CENTRALIZED WEB DELIVERY Challenge: Integrate new offerings January New student ERP rollout April Degree student online enrollment May Continuing Ed instant enrollment June itunesu launch August Degree Student web mail launch August Portal launch inside.artcenter

5 EXISTING IDENTITY RESOURCES What did we have to work with? Independent systems of record Two active directory domains Local logins on different servers (i.e. ftp / www) 17,000 sendmail records (accounts + aliases) Conflicting student ERP generated usernames Mixed Numeric and alphanumeric login names Different login names in different systems Many users with multiple passwords

6 IDENTITY MANAGEMENT What did we want from this effort? Create a common method for authentication Plan as open an architecture as possible to grow service for future requirements Applications have access to common person data that is useful from app to app Users passwords can be Self Service Front line support can provision accounts

7 WHERE DO WE START?

8

9 2007 STARTING OBJECTIVES What do we need for software and hardware? Directory (LDAP/AD) / WWW / App Serv Preferably >= two servers per service Who will we get the software from? Purchase from Oracle, Microsoft, Sun Write it ourselves What systems need to be tied to IDMS first? Student ERP (Datatel) / Active Directory WWW Services not yet built Find the right consultant to help

10 SOFTWARE ANALYSIS Oracle Microsoft Sun Layered products based on (LDAP/Oracle) Professional Services Required Layered products based on (AD LDAP (ADAM)/MSSQL) Professional Services Required Layered products based on Sun JES (LDAP/Java) Professional Services Suggested Comfort Level: Moderate Comfort Level: Low Comfort Level: Moderate Cost: $$ Cost: $$ Cost: $ (Academic Discount)

11 2007 INTEGRATION OBJECTIVES Portal Username Password Role (All Constituents) Primarily for student use at first Student ERP Username Password Student ID (All Constituents) Student /Faculty +Staff online use itunesu Webmail Username Password Role (Student/Faculty) New services offered with the portal LDAP LDAP LDAP

12 PHASED GAME PLAN

13 PHASED GAME PLAN 1. Active Directory changes in advance of IDM integration 2. LDAP needs in advance of IDM integration 3. IDM resource integration Initial deployment 4. Single sign-on integration 5. Maintenance and future integration policy

14 PHASE 1 ACTIVE DIRECTORY 1. Student username migration from studentid_num to match username 2. Password policy changes 3. Communication to reduce impact to users 4. File and folder regeneration 5. Testing and support

15 USERNAME CREATION DURING MIGRATION AD ACCOUNT PROVISIONING FEEDS COLLEAGUE USER STATE USER KNOWN USER UNKNOWN NORMAL FEED (ALL/ADD/DROP) FOUND POSITIVE USER MATCH UMRA PICKUP CANNOT ASSERT ABSOLUTE USER MATCH ACTIVE DIRECTORY and STORAGE SETUP Admin Arbitration

16 PHASE 2 LDAP 1. Build LDAP server farm 2. Build LDAP OU structure 3. Decide uid method for LDAP usernames: uid=username cn= first last 4. Create attribute model based on eduperson (register PEN at pen.iana.org) 5. Assess needs of individual applications

17 PHASE 3 IDMS INTEGRATION 1. Attach active directory domains to Sun IDM 2. Establish LDAP link with Sun IDM: LDAP has no user accounts yet 3. Compare test exports between active directory and lists of sendmail accounts 4. Import active directory accounts into Sun IDM, pushing AD accounts into LDAP 5. Load text files of sendmail accounts into SUN IDM, pushing accounts into LDAP

18 PASSWORD CAPTURE MECHANISM LDAP PASS AUTH Sun IDM LDAP ACTIVE SYNC

19 PHASE 4 SINGLE SIGN ON 1. Set up Shibboleth server 2. Integrate portal applications Based on time restraints, we cheated and used basic PHP trust scripts for SSO. We do have plans for Shibboleth in the future.

20 PHASE 5 MAINTENANCE AND THE FUTURE 1. Define IDMS support roles 2. Cross train support leads as project progresses 3. Constant review of practices 4. Management priority set on future application integration 5. Completion of Faculty and Staff issues created by migration based on Students

21 PROJECT PROGRESS Milestones reached June-August 2007 New student usernames introduced between terms Attribute structure still in development LDAP password capture mechanism for existing logins worked extremely well Custom script based solution written: ERP query LDAP before account creation Portal launched for fall online registration

22 IMPLEMENTATION TO MAINTENANCE Delivery mode change in project New processes are required to replace old forgotten processes Data flow issues are not all equal Required: Documentation of attribute flow Determine exception handling methods

23 ATTRIBUTE TOPOLOGY DOCUMENTATION CUSTOM USERS USERNAME FEED Colleague Registry ColleagueID Username PrimaryRole IDM RECONCILE IDM ACTIVESYNC Password + NewAccount Whoami table WA username AD username CampusID ColleagueID Default Password PrimaryRole Department

24 LESSONS LEARNED Start small Decide authority of historical user naming Learn from old problems IDMS is replacing Determine minimum attributes needed Build with intent to rebuild and reorganize Good design will resolve unrecognized details Redundancy is vital for centralized resources

25 2008 What are we delivering this year? Attribute flow topology migration to Oracle New blogs server implementation New course management system implementation Alumni access to online campus resources Instructor and Alumni maintenance of forwarding LDAP based routing

26 FUTURE OBJECTIVES Requests for more, more, more! IDMS will provision OS accounts IDMS will manage AD and Exchange Library integration (Millennium) Equipment rentals integration (Webcheckout) Dynamic lists via LDAP

27 THANK YOU Jason Blackader