This Internet2 Draft will expire on May 22, 2005.

This document is a submission from the MACE-CourseID WG of the Internet2 Middleware Initiative. Comments should be sent to the mace-courseid-comments at internet2.edu mailing list.

Abstract

This document uses several simple learning scenarios to illustrate how CourseID information models and attribute definitions, together with the Shibboleth System, can be used to solve authorization and resource usage control problems in learning environments that cross institutional boundaries.

1. Just in time provisioning into a Course Management System (CMS)

1.1 Overview

Most course management systems use a local table or file of accounts that are permitted to access a course, usually with one or more roles attached, such as "student", "designer", "instructor", etc. In this scenario, a user accesses a CMS course protected with Shibboleth for the first time and has not been given prior access to the system. It is advantageous for the user experience if their origin site can assert their right to access the course in one or more roles during the Shibboleth attribute exchange. The CMS could then use the attribute(s) to provision the user into the course and immediately grant access, with appropriate auditing and controls.

1. The Browser User accesses a link that takes them directly to the course offering in the service provider's CMS, or to the Shibboleth Inter-site TransferService with parameters that will direct them to the CMS site after authenticating.
2. The Browser User signs on to the CMS and specific attributes are made available by the Identity Provider: eduPersonTargetedID is passed as an identifier that the Identity Provider and Service Provider share for the authenticated Browser User. A value of eduCourseMember is passed that asserts both the identifier of a specific course offering within the Service Provider's CMS and a defined role or roles that the Browser User is authorized to assume for the specific course offering. The syntax and semantics of these values are specified in draft-internet2-mace-courseid-ldap-educourse-00.
3. The CMS examines the attributes, if any, and can choose to synchronize the access rights they represent with its own locally held access rights. This may include creating a local account dynamically to hold the Browser User's rights and their work in the course.
4. If access should be granted, it is given. If not, an explanation is provided.

2. A university decides to implement the technology required to support the TEACH Act

2.1 Overview

The TEACH (Technology, Education and Copyright Harmonization) Act, which provides for the use of copyright-protected digital information in web-based, or distance, education. One provision of the TEACH Act is that the institution must use technology to limit access to copyright-protected digital information by limiting access to registrants of the course using the materials.

The university surveys its campus and discovers that many proprietary methods for limiting access are available, including course roll functionality in multiple courseware/learning management systems, passwords issued by faculty to their students, etc. The one commonality is that the university issues a secure NetID to every student and faculty member.

Upon investigation, the university determines that what is needed is a standardized authentication and authorization process that first authenticates the student as a member of the university and then authorizes the student for access to a resource based on the student’s enrollment in an identified course. This authorization requires a standardized way of representing a person's course enrollment and also a standardized, unique way to identify each course.

The university determines that the Shibboleth suite provides a standardized way to authorize access to resources, that the person's RegistryID is the appropriate persistent and unique person identifier, and that eduCourse attributes, eduCourseOffering and eduCourseMember can carry, respectively, the unique identifier for the course offering and the assertion of enrollment in a given course offering in a given role.

2.2. Flow of Events

1. The Browser User accesses a link that takes them directly to the course offering in the service provider's CMS, or to the Shibboleth Inter-site TransferService with parameters that will direct them to the CMS site after authenticating.
2. The Browser User signs on to the CMS and specific attributes are made available by the Identity Provider: localEduPersonRegID is passed as an identifier that the Identity Provider and Service Provider share for the authenticated Browser User. A value of eduCourseMember is passed that asserts both the identifier of a specific course offering within the Service Provider's CMS and a defined role or roles that the Browser User is authorized to assume for the specific course offering. The syntax and semantics of these values are specified in draft-internet2-mace-courseid-ldap-educourse-00.
3. The CMS examines the attributes, if any, and can choose to synchronize the access rights they represent with its own locally held access rights.
4. If access should be granted, it is given. If not, an explanation is provided.
5. When the course offering is no longer active, these values for eduCourseMember will no longer be generated and transported, so access to materials associated with this specific course offering will be effectively cut off in conformance with the terms of the TEACH Act.