Early Draft of the Specifications for community review
Presented to UH developers on 9/16/2011
- Specifications:
- Desirable Objects
- Acknowledgements - as in I hereby acknowledge that I have read and understand E2.214.
- Certifications - as in successfully demonstrating via test questions that I have read and understand E2.213 (not a Phase I deliverable).
- Audiences (types of users)
- Users have UH Credentials and can assert acknowledgements and pass certifications; no role-based access controls are required at this time.
- Policy Representatives can create and manage their own certifications.
- Acks and certs must be owned by either someone(s), group/dept accounts are eligible.
- Multiple apps can reference a single acknowledgement or certification, and a single app can reference multiple acknowledgements or certifications.
- Clarify the purpose of acknowledgements and certifications for continued access to apps; to convey responsibilities. Not an authorization or provisioning tool.
- Explain certifications as demonstrated knowledge.
- Admins can provision and de-provision owners.
- GUI
- Web-enabled self-service tool for end-users to be merged with the new /username redesign.
- Requires UH credentials to use
- Users can view all certifications and acknowledge any of them.
- User is informed of which certifications have been acknowledged and when.
- User can easily distinguish which certifications should be acknowledged in the near future so as not to have to come back very soon.
- Email notifications for pending expirations
- allow policy owner to select notification schedule; develop selection parameters; for now we only need two patterns, short and long, one month and one week with weekly reminders
- Policy Reps can create, update, enable/disable, delete, reassign or extend ownership requires a request being sent to an admin;
- deleting and disabling has potential ramifications.
- API to pass if the application reference an acknowledgement or certification that is missing or disabled
- Admins can provision/deprov and enable/disable Policy Reps;
- must a person be fac/staff to be authorized? no, admins determine this
- are grouper groups appropriate for tracking Policy Reps? tbd
- UHIMS Life Cycle should also trigger deprovisioning
- Data Storage
- Set this up as a separate service with its own database.
- Data tracks each user's acknowledgements and certifications and the date last updated successfully.
- Expiration dates are NOT by definition in scope. It is up to the consumer of the info to apply business rules.
- Life Cycle: Data is removed when the user no longer has an active affiliation with UH. Returning to UH imposes a fresh start.
- Data Retrieval during authentication to determine authorization
- LDAP
- CAS - upgrading to CAS 3.x may be a prerequisite (not a Phase I deliverable)
- Shibboleth via attribute release policy
- Development Phases
- Phase I: Acknowledgements, single check box
- Phase II: Certifications, pass/fail testing process
- Requirements for building questions and answers and answer keys need to be defined.
- Phase III: not planned, only to be considered if sufficient demand for expansion of functionality
- Parkinglot
- tracking who took which online quizzes, etc and reporting back to a dept, unit, etc.
- support for UH related organizations; for more general use
- POs may want to track who amongst their staff have done the confidentiality agreement
- Departments may want to impose their own acknowledgements on their own staff or on their own guests.
- Desirable Objects