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 require a System of Record (separate data store) for Guests/Affiliates? (e.g. NOT in HR or Student systems)
- Do you intend to use a separate authentication mechanism/system for Guests/Affiliates?
- Do you intend to create 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? If so, will guests that need to access these be issued a Campus Credential?
- Is it possible for some guests to have both a Campus and a Guest Credential?
- 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 if they authentication systems are separate?
Policy Steps
Self-Assessment - Questions
- Do guest accounts require sponsorship?
- Who may sponsor guests?
- What data can be used to verify (vet) the identity of a guest?
- Life cycle: How long may guest identities remain "active" (authentication enabled)?
- Life cycle: How long may guest identities remain in the system?
- Are guest identities in a separate data store or in the same data store as identities of "regular" affiliates?
- Are there attributes to indicate the identity is a guest, who the sponsor is, when the account expires, etc.?
- May guest identities have attributes indicating affiliation (e.g., faculty or student)? Will the affiliation be stored in a standard attribute like eduPersonAffiliation?
- How will guest identities be supported? Central help desk or a special guest help desk?
Requirements/Prerequisites
Checklist
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
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