Standardizing Identity Management
Transcription
Standardizing Identity Management
Standardizing Identity Management Two Different Approaches from Technology and Institutional Archaeology Edward Aractingi - Marshall University Sherry Tirko, Chuck Moore, Nick Roy - Penn State Standardizing Identity Management Two Approaches • • Penn State – The Central Person Registry and Solving The Mystery of The Heterogenous Primary Appointment Marshall – Implementing Microsoft Forefront Identity Manager and Integrating With Office365 [2] © 2014 Internet2 Background [3] The Central Person Registry • Stories from “the long road to productionalization” Photo by Jill Scott, idea for title by Nate Klingenstein • • Started out with a trip to a CIC Meeting at Ohio State in 2007 Registrars, CIOs, other stakeholders decided to focus on IAM [4] The Central Person Registry • • • • • • • • • Penn State attendees including Kevin Morooney and Renee Shuey identified a need for a single source of truth for person records at the university 2008 – Formed “IAM Technical Architecture Group” as part of recommendations to VP for from Penn State stakeholders 2008-2010 – CPR requirements gathering with stakeholders 2010 – CPR implementation begins Spring, 2013 – Identity Services formed as a department to manage the CPR and related IAM systems September 2013 – CPR primed with data and in production Where we are now: October 2014 – Integrating with new PeopleSoft Campus Solutions Student System Deadline for Admissions Integration: April, 2015 Some rough edges to work out, including what to do about primary appointment, when there are (at least) 3 different HR systems at the university [5] Business Relationships – Background • Overcoming the past – Data – mine, yours, and ours – Silos [6] Business Relationships - Now • The new environment – Building trust – Data sharing – Shared decision making [7] CPR Data Flow • Real-time updates • Inbound – SOAP Web Services – CRUD operations • Outbound – JMS Queues – Change Notifications [8] Populating the CPR Data • No real-time updates • Comes in batch • Inconsistent • Overwritten daily • Has to be ‘staged’ [9] One Record To Rule Them All • Which record is ‘primary’? • Update policy – Which system has the correct data? – How do we keep systems in sync? [ 10 ] Marshall University- Background • Marshall University was faced by the same problems that many other institutions are facing • Account provisioning was automated but limited • Role management was not optimized and accurate [ 11 ] Marshall University- Legacy System • Ellucian Banner • Active Directory • A combination of sql, ProC, linux shell, and Windows shell scripts. • Original script authors no longer available • Only generated new account ID and email address, no additional attribute data. [ 12 ] Marshall University - Solution Overview • • • • Microsoft Forefront Identity Manager 2010 R2 FIM Portal Custom Banner Tables Office365 DirSync [ 13 ] Marshall University - Project Plan • Measure twice… cut once [ 14 ] Marshall Diagram Office 365 Exchange Password Reg /Reset DirSync User Accounts Ac(ve Directory User Accounts MUFIM, Windows Server 2008R2 + Sharepoint MUFIMSQL, Windows Server 2008 r2+ SQL Server MUFIMPW, Windows Server 2008 r2+ Sharetpoint Banner on Oracle RHEL Linux OS. FIM Banner Metaverse [ 15 ] New source Tables in Banner • • • • ad_person ad_person_delta ad_groups ad_groups_desc Ed Aractingi WVSTC 2014 Arac(ngi Arac(ngi Arac(ngi Arac(ngi Arac(ngi Arac(ngi MemberOf IDM-‐AMS_OFFICE365 MemberOf IDM-‐APPACCEPT MemberOf IDM-‐APPLICANT MemberOf IDM-‐BANNER MemberOf IDM-‐EMPLOYEE MemberOf IDM-‐FACULTY [ 16 ] 1 6 Banner BANNER GENERAL, HR, STUDENT SPRIDEN SPBPERS GOBTPAC BANNER ROLES AS_EMPLOYEE_PROFILE GOREMAL GOROROL GLBEXTR FIMS_AD_PERSON FIMS_AD_GROUPS_VIEW PROCESS PERSON DATA PROCESS GROUP DATA FIMS_AD_PERSON_DELTA FIMS_AD_PERSON_TMP AMS ZSASVRE FIMS_AMS_GROUPS FIMS_AD_GROUPS FIM DELTA SYNC FIM FULL SYNC FIM METAVERSE Ed Aractingi WVSTC 2014 BANNER POPSELS Credit: Maynard, B. & Enterprise Apps team [ 17 ] 1 7 The Delta Sync Process FIM delta sync agent ini(ates process If a new record is found, a delta record is wriVen to the delta table with “Add” FIM delta sync reads delta table and processes changes to metaverse stored procedure executes on staging tables If a record has changed, a delta record is wriVen to delta table with “Modify” FIM AD agent updates AD from metaverse a copy of the person table is made, then the person table is regenerated. A difference check is performed on the updated table and it’s copy For new accounts, services are provisioned based on group membership Credit: Maynard, B. & Enterprise Apps team Ed Aractingi WVSTC 2014 [ 18 ] 1 8 Username lookup – Integration w/Portal Credit: Cummings, J. & EnterpriseApps team Ed Aractingi WVSTC 2014 [ 19 ] 1 9 Workflow Exchange Server Active Directory FIM Metaverse FIM Tables Banner Entered in OnBoarding IIF(IsPresent(rawbirthdate),rawbirthdate,employeeID) Ed Aractingi WVSTC 2014 [ 20 ] 2 0 FIM Portal Ed Aractingi WVSTC 2014 [ 21 ] 2 1 Password Registration Ed Aractingi WVSTC 2014 [ 22 ] 2 2 Marshall University - Password Reset Ed Aractingi WVSTC 2014 [ 23 ] 2 3 Lessons Learned [ 24 ] Penn State- Lessons Learned • The basis for de-siloing is TRUST • Achieving IAM technical solutions can’t happen without • Establishing good relationships • Developing a shared understanding Marshall University [ 25 ] WVSTC 2014 Marshall University - Lessons Learned • • • • • Planning!!! Garbage in- garbage out Measure twice, cut once Get assistance (we use CampusEAI IDM services) It’s TEAM work Marshall University [ 26 ] WVSTC 2014 Questions / Discussion Contact Information Edward Aractingi – [email protected] Sherry Tirko – [email protected] Chuck Moore – [email protected] Nick Roy – [email protected]