Introduction
This document lists the recommended policy, process, and technical steps required to implement a Guest/Affiliate System. You may use the checklist to assess your organization’s readiness to implement a guest system or use it to serve as a checklist for those tasks that remain to be completed. Most sections of the checklist have three parts: policy steps, business practice steps and technical steps. Each batch of steps is sequential.
Term Definitions (for this document)
- Member - implying that the individual's affiliation to the institution is Student, Faculty or Staff (active)
- Guest/Affiliate - used interchangeably in most cases, however, primary distinction is that they are NOT members. (Guest can have a shorter-term or less frequent association, versus affiliate could be longer-term or a lifetime affiliation such as Alumni).
- Campus Credential - a username/password pair or digital certificate issued to members of the institution (e.g. a NetID).
- Guest Credential - a username/password pair that is distinct from a Campus Credential.
Scoping Questions
- What are the use cases for the creation of a Guest/Affiliate System?
- Do you required a System of Record (separate data store) for Guests/Affiliates? (e.g. NOT in HR or Student systems)
- Do you intend to create a separate authentication mechanism for Guests/Affiliates (will they have a separate Guest Credential distinguishable from a Campus Credential)?
- Will some of your services, applications, resources be accessible using both a Guest Credential and a Campus Credential, or will guests that need to access such shared services be issued a Campus Credential?
- Will (some) guests be issued a Campus Credential? If so, will they have BOTH? (see next question)
- If you intend to have separate credentials (those for Guests and those for Members or "special" guests), will you TRANSITION individuals between the authentication systems?
Policy Steps
Self-Assessment - Questions
* Who may sponsor guests?
* Identity vetting
* Life cycle: How long may guest identities remain "active" (authentication enabled), remain in system
* Markers for guest identities: identifiers in same namespace as "regular"? attributes indicating guest or sponsorship or expiration?
* May guest identities have attributes indicating, e.g., faculty or student? eduPersonAffiliation of affiliate or member?
* What support will be provided?
Requirements/Prerequisites
Checklist of Steps
Business Practices Steps
Self-Assessment - Questions
* Designation of roles or individuals who can sponsor guests
* Approval process work flow
* Record keeping
* Alert services that consume identity data about guests; will services differentiate between guests and "regular" members
* Support processes for guests (may have different process for password reset or assistance with services)
Checklist of Steps
Technical Steps
Self-Assessment - Questions
* Schema extensions if necessary
* Guest sponsorship form; identifier generation and insertion into Directory
* Attribute values assignment
* Initial password / account claim process
* Additional provisioning (i.e., generation of accounts based on digital id)
* Revocation and expiration processing