You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Introduction

This document is a draft of a self-assessment tool to help campus IAM architects (and others) determine how best to provide access to campus services for guests and other affiliates who do not have a campus credential.  Users of this tool should also refer to the companion document "Guest Affiliate Problem Statement" (also a working document) for a better understanding of the Guest Affiliate problem.  The sections of the assessment are divided into three parts: policy, business practices and technical.

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 (NetID) or digital certificate issued to members of the institution (e.g. a NetID).
  • Guest Credential - a username 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

Self-Assessment Questions
  • Do guest accounts require sponsorship?
  • Who may sponsor guests?
  • How long can an individual be a sponsor?
  • Must a sponsor renew the ability to sponsor accounts?
  • 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?
  • Can service providers decide to accept/deny all guest credentials?  On what basis?
  • Can guest credentials be used to access external services (e.g. Federated) and if so, with what ePPA?
  • What types of guest transactions need to be logged for auditability? (provisioning, updates, de-provisioning, reactivation of accounts, access/authorization, etc.)
  • Is guest authentication logged/audited differently than member authentication?

Business Practices

Self-Assessment Questions
  • What is the process to designate individuals who can sponsor guests?  Is approval part of the process and, if so, what is that process/work flow?
  • What records are kept with regard to sponsors?
  • What is the process for renewing a Sponsor?
  • What is the process like when a sponsor leaves (e.g., retires, severs employment), but active accounts, sponsored by this individual, remain?
  • Will services that consume identity data about guests differentiate between guests and "regular" members (e.g., alert services)?
  • What do support processes for guests look like (e.g. initial password distribution, account claiming, password reset, assistance with services)?
  • What is the process for terminating a guest (credential)?
  • What is the process for distributing initial passwords for guests?
  • What is the account claiming process for guests like?
  • Can a guest credential (ever) be reused by someone else?
  • What are the consequences for misuse of a guest credential (accountability of "guest", Sponsor, department, etc.)?

Technical

Self-Assessment Questions
  • Will schema extensions in any data repositories be necessary?
  • What type of forms (paper or web-based) need to be generated?
  • Will there be modifications to identifier generation algorithms?
  • In what systems do guest identities need to be added (e.g. directory, guest SOR)?
  • What attribute values need to be assigned for guests?
  • Will provisioning system modifications be required to support guests?
  • Will modifications need to be made to systems to support revocation and expiration of guest accounts?
  • No labels