Collaboration & Commitment

Size: px

Start display at page:

Download "Collaboration & Commitment"

Jasmin Gallagher
6 years ago
Views:

1 Collaboration & Commitment The keys to successful delivery of IDM at the University of Greenwich Joshua Fry Head of Infrastructure Information & Library Services

2 Past Present & Future The IDM Timeline Why we did it What worked What was hard Presentation Overview Technical Overview Architecture: Before and After Collaboration Commitment

3 AD Migration from Netware: File, Print, Auth IDM and Oracle HR (Staff) integration - ARMS Upgrade - Admin Portal (UserDB replacement) - Netware fully decommissioned IDM integration commences IDM integration completed Commitment 2015 Future ARMs; IDM and Netware integration IDM and AD integration IDM and Banner Student integration Timeline to IDM

Pre IDM & ARMS - Business process and support problems Manual processes for part time teaching staff

Composition of user ID limited range of IDs available; manual process to delete.

Very difficult to provide access to external people affiliated with the university but not direct

Lots of legacy and bespoke, systems and processes; single points of failure, knowledge sinks.

4 Pre IDM & ARMS - Business process and support problems Manual processes for part time teaching staff start/end contracts: always left gaps and dissatisfied staff. Composition of user ID limited range of IDs available; manual process to delete. Some overlap of IDs problems with accessing IT resources. Very difficult to provide access to external people affiliated with the university but not direct employees, such as: contractors, partner college staff, guests etc. Computer says no! Lots of legacy and bespoke, systems and processes; single points of failure, knowledge sinks. Multiple systems operating autonomously, with bespoke and custom integration. Has anybody seen the manual? No single enterprise architectural view of identity management as an information system or as a technological asset.

5 PRE IDM Legacy student account management process

6 Pre IDM Legacy staff account management process

7 Constraints on IDM project:

8 How did we get started? We had a clear vision of the technological benefits to the University. which in turn supported strategic goals of enhancing the student experience, and underpinning quality in teaching and learning. Why is that important? Simplifying, integrating and automating processes enables staff and students to gain access to resources as efficiently as possible & support staff freed from manual processes can concentrate on service enhancement and add value adding tasks.

9 We knew we could not get there alone We engaged with consultants to provide the domain expertise, and the technological and implementation experience to bridge the knowledge gap.

10 IDM initial phase

11 IDM AD phase

12 IDM Banner student phase

13 IDM staff HR & Banner phase

14 Technical overview: IDM drivers and data flows prt 1. student The Banner student driver manages applicant and student accounts. Staging tables in Banner are used as the authoritative source for student identities and their enrolment details in the Identity Vault. The driver polls a Banner event log table to detect new or updated Banner records to process them. The driver operates in trigger mode and this is informing IDM of changes to the data. Students may have multiple concurrent enrolments or programmes they may be a current student in one programme whilst also being an applicant for another. Users are added to a group for each programme they are on. Banner access control rules (based on registration status, person holds, programme holds etc) are also setup in IDM and these are used for controlling access to target systems. Selected attributes, such as addresses and usernames, flow from the Identity Vault to Banner. When a student leaves the University or there ceases to be an association between and applicant and the University, IDM initiates de-provisioning actions, in other connected systems, via internal triggers. staff Staging tables in Oracle HR are the authoritative source for staff identities and assignments in the Identity Vault. The driver polls a HR event log table to detect new or updated HR records to process them. This driver operates in trigger mode and this is informing IDM of changes to the data. Each member of staff may have multiple concurrent assignments and the details for them are all added and maintained in the Identity Vault. Access rule matrix based on HR business rules (contract start and end dates, employment and assignment statuses, etc) are setup in IDM and used for controlling access to target systems. Selected attributes, such as addresses, usernames, Banner IDs flow from the Identity Vault to Oracle HR. When a member of staff leaves the University IDM initiates deprovisioning actions in other connected systems. cont.

15 Technical overview: IDM drivers and data flows prt 2. Active Directory Three IDM AD drivers have been implemented to automate provisioning, de-provisioning and management of accounts in Active Directory from the Identity Vault and based on defined business rules. Windows servers within the Active Directory environment are used as Remote Loaders for processing events and synchronising information from IDM to Active Directory and vice versa. The IDM Active Directory drivers maintain the Active Directory OU hierarchy structure for User accounts in the two subdomains. IDM creates the OUs based on the organisational structure from Oracle HR for staff and the Faculty structure from Banner System for students. Usernames and passwords The naming (CN) of new user account is in the following format : CN = 1st char of Given Name + 1st char of Surname + 4 random digits + random character. e.g. cn=ab1234x An eight character random Universal Password is generated for the user using a Universal Password policy. The password must contain a combination of uppercase characters, lowercase characters and numbers. User account placement in the OUs are based on user s primary department. The drivers add student user accounts to the security and mail distribution groups for each of their active programmes, staff accounts to the security and mail distribution groups for each of their active assignments. The AD domain staff driver also creates exchange mailbox and mail attributes for the staff domain users.

16 ARMS Affiliate Records Management System (ARMS) ARMS was developed and customised, for the University of Greenwich, by Salford Software, now ProofID, in ARMS is configured to connect to the University s Banner system for duplicate checking, and to generate Banner IDs this is needed for the University s ID card and to access Banner system resources. The ARMS database has inter-database communications via SQL for retrieving the University s organisational hierarchy structure and site information from the tables/views in Banner. An IDM JDBC driver synchronises affiliate information from ARMS to the Identity Vault. It also writes back required details from the Vault to the database table in ARMS. IDM generates usernames for the affiliates and manages; also provisions and de-provisions affiliate accounts in the Vault and connected systems. ARMS: - an authoritative source for affiliate accounts. - a self-service on-line registration for affiliate users to request accounts. - a web interface for the approvers in the departments to manage the accounts and give access to resources for their associated users.

17 Resource What was hard Budget Time

18 Vision Technology What worked well Data

19 How would we approach an IDM project now? Apply an EA (Enterprise Architecture) approach.

The importance of collaboration To leverage skills and domain experience from multiple contributors To collate, articulate and understand process across the organisation To engender an enterprise

20 The importance of collaboration To leverage skills and domain experience from multiple contributors To collate, articulate and understand process across the organisation To engender an enterprise architecture approach; understanding the impact To align the objectives of the project to delivering University strategic goals Approaching IDM unilaterally was impossible; needed support form multiple stakeholders Trust between collaborators and participants in the implementation.

The importance of commitment Tenacity to see the project through Keep up team morale and enthusiasm Changing staff, resources and strategic landscape required versatility in approach Need to keep all

21 The importance of commitment Tenacity to see the project through Keep up team morale and enthusiasm Changing staff, resources and strategic landscape required versatility in approach Need to keep all parties focused on the outcome and achieving project completion Strength of commitment to believing the value of the project and being able to communicate that to others. Stakeholders and participants needed to be prepared for the long haul Confidence in the direction of the project and that objectives would be achieved

Current status ARMS upgrade Remove residual system dependencies on UserDB Change wireless authentication Upskill and train staff in IDM driver

22 Current status ARMS upgrade Remove residual system dependencies on UserDB Change wireless authentication Upskill and train staff in IDM driver configuration, and other deep maintenance Consider other support models Incorporate IDM into EA cycles to ensure technology is aligned with IT strategic objectives

23 Questions?

ICT Systems Administrative Password Procedure

ICT Systems Administrative Password Procedure Related Policy Responsible Officer Approved by Approved and commenced July, 2014 Review by July, 2017 Responsible Organisational Unit ICT Security Policy ICT