UKRI IAM Project
Tim Kells, John Patrick
Tim:
- Nearing first deliverable for core funtionality, aiming for end of October - UKRI Greenfield
- Low risk for users, with main change being taking the feed form UKRI to proofID
- Main change will be joiner/leaver can be managed within the Greenfield service
- Objective is one ID for SSO across STFC and all strategic partners
- Timeline - go through next 6 weeks to work out implementation plan
- Through to mid December
- Understand routes and change plan
- Implementation from January (Design, built test) through to ~ Sept 2023
- Implement with considerations of Low Risks to Maximise Benefit
- Slide to provide an overview due to be distributed end of next week
John:
- Collaboration is key - take the Impact and use case set and use these to build the test case set, so that those produced do represent the full case
- Architect has full view, and keen to be engaged with the STFC side
- Please raise questions as you have them
Questions?
- Paul Barrett - four data feeds? Thought there would be more
- DLS HR (should this have been ISIS?), Oracle, UAS, Direct Web Interface
- Current process for RFI, for example, is they send users and these are directly entered
- One aspect of the minimal viable product would be an API for sending information in
- DLS HR is to prevent any changes with that causing issues.
- UAS covers extensions and expiry dates
- From Tim, pasted:
Establish trusted sources of identity data feed daily import
into Identity Vault from
o Oracle HR (file based)
o Diamond Light Source – User Administration System
(DLS UAS) (API based updates)
o ISIS HR (API based updates
- Users/Individuals, Identities and Roles giving different access levels
- Will need mechanisms for a user to change an affiliation, and how data transfers with them
- Need to understand models, including data ownership and how things may move and how this will fit within implementations
- Some people may move around, and grants follow with them - and understanding how that complexity fits within use and test cases
- Typically it has gone to a data steward or owner to establish ownership - this will require consideration to understand fully, and so as to consider business concerns
- A person is an individual, and access should be layered on the person. The Identity Management system should support any data management flows, rather than having data management layered in this process
- Information about a user that changes should be propagated as it changes
- David - what is the primary key for a person, and then what are attributes attached
- Need to understand the process of how a FedID and attributes may change when a user moves. Risks need to be considered, and future implementations will likely consider roles assigned to a user as opposed to their ID
- Access needs to consider a number of different axis, not just an individual
- Purpose should be to consider route to a newer, fine-grained, system rather than recreating "what-we-do-now"
- Colin - need to get to a point where we can all do the same things.
- John - large blob of use cases, which can grow and become more accurate. Matrix for understanding which are relevant to which group. Excel doc for mapping this.