DM - 2008-11-06
- ScottS
Owned by ScottS
Attendees
Agenda
- Finalize Overall Goal/Scope of Project
- Finalize High-Level Release 1 Goal/Scope
- Define Components Required for Release 1 Goal/Scope
- Defining should allow us to estimate size of work needed to be done for planning
- Recognize throw-away components (bridge) that may be replaced in release 2
- Recognize components/implementation details that allow for implementation of future requirements
Notes
Goals
Project goals
Software to create a central, normalized, repository of identity data from various SORs and present a canonical representation of the data for consumption by downstream systems in the identity infrastructure.
Identity Data includes biodemographic data, courses, credentials, account information, etc.
Release 1 Goals
Create a minimal working version of the repository to support Guest Management. Keeping in mind the general goals.
Guest Use Case
What can a guest want access to?
- Applications
- Network
- Systems
- ID card
- Building
- Other Resources
What might we want to do with a guest?
- Sponsor
- Alert
High Level Overview / Flow
- Input
- Validation
- Reconciliation
- Transformation
- Id Creation
- Downstream System Output
Guest Management "System"
- Create
- Edit / Update
- Delete
- View List / Status / Etc.
Inputs
- Web UI [Data entry via Person]
- Batch [system]
Authorization
- Detailed authorization model for the creation of guests. Basically an open system (i.e. anyone can use it) but restrictions on what you can do. I.e. students can only create Parent roles, whereas a departmental administrator may be able to create Visiting Professor roles. In addition, depending on role, more or less data may be required to input.
Open Questions
- Self-Account Creation?
- Are applicants also guests?
- Affiliation/Role Assignment for Guests
- Are addresses, etc. attached to roles or affiliations?
- Delegation of responsibilities, i.e. admin putting in guest requests for a professor?
- Flow of adding a guest to the system?