Guest Affiliate System Self-Assessment Tool

Terms

For the purposes of this topic (and the referenced documents) the following terms are defined:

Affiliation - the "relationship" an individual has with an institution or organization

Traditional Member - an individual who is a Student, Faculty or Staff (equates to the eduPersonAffiliation attribute "member") - "Core Population"?

Affiliate - an individual with a "non-traditional" relationship/affiliation to an institution (e.g. Guest, Parent, Alumni, Library Patron, Donor, Contractor, Vendor, Visitor, etc.)

Guest - a type of affiliate usually with a short-term or temporary relationship to an institution (whereas other affiliates could have longer-term or permanent relationships).

Entitlement - a "right" to access certain services, usually granted or authorized by the owner of the service and provisioned to individuals as a result of membership in a group, a specific role, or via a rules-based mechanism. and provisioned to individuals as a result of membership in a group, a specific role, or via a rules-based mechanism.

Overview (problem description)

Almost all institutions have a need to provide services to, or at least "track" non-traditional populations that have some relationship with their college or university.  In many cases, the traditional populations of faculty, students, and staff are provided certain "default services" (email, network access, access to library services, parking access, learning management systems, etc.) as a result of their enrollment or employment at their institution.  Being able to distinguish the traditional members of an institution from its affiliate populations requires some way of identifying an individual's affiliation, as well as being able to authorize access to the services they are entitled to.

This might all be handled by one system if an institution is starting from "scratch" - given that all users' affiliations are identified, and given there is a way to authorize or deny access to services.  However, in many institutions, particularly those that have had an identity management infrastructure in place for some time, authentication implies authorization - meaning that if you can "log in", you are assumed to be a "member" and get access to many services across campus.  Unless all your applications and services have the ability to make an access determination based on who you are (your affiliation type) and/or specific "entitlements", roles or group memberships, then you need to somehow separate these two major populations.

A formal document stating the Guest Affiliate Problem is referenced below under the Tools section.

Also, the use of Social Identities for guest access is very much a "hot topic" in the IAM space.  Please see the link to the Social Identity discussion Wiki under Links below.

Use Cases (examples)

Use Cases are examples that highlight a specific problem.  In the case of guest systems, these would consist of situations where the current IAM environment or infrastructure does not adequately support guest identities.  In many institutions "non members" are added to an existing system of record (such as the HR or Student system) in order to facilitate access to campus resources.  This is usually less than ideal and there is frequently resistance on the part of the data steward responsible for that system.

Generic Use Cases for Guest and Affiliate systems can be found below, as well as a cross-posting of Generic and Specific Use Cases for OpenIDs and Social Identities from the SocialIdentity Wiki.

  • What data gets captured
  • Vetting of data
  • Auditing
  • What type of standards apply?

Requirements

  • Sponsorship
  • Expiration/Renewal

Case Studies and White Papers

  1. USC iVIP Guest/Affiliate System Overview:USC iVIP Overview.pdf
  2. USF Guest/Affiliate System Overview: USF Affiliate-Guest system info.pdf
  3. University of California, Berkeley: University of California, Berkeley Guest Management
  4. USC Self-Service Guest Registration: USC Federated Guest Registration Service-2011-07-14.pdf

Tools

  • No labels