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 – aractingi1@marshall.edu
Sherry Tirko – slk24@psu.edu
Chuck Moore – crm117@psu.edu
Nick Roy – nsr11@psu.edu