Difference between revisions of "CAS"

(Added assumption and group information)
Line 10: Line 10:
*[[CAS Directory]] - [https://login.middlebury.edu/directory/ https://login.middlebury.edu/directory/]
*[[CAS Directory]] - [https://login.middlebury.edu/directory/ https://login.middlebury.edu/directory/]
== Applications being converted to CAS ==
== Applications currently being converted to CAS ==

Revision as of 11:36, 30 April 2009


Middlebury College uses the Central Authentication Service (CAS)[1] developed by Yale and maintained by Jasig for single-sign-on to our suite of web-based applications.

Supported Applications

Applications currently using CAS

Applications currently being converted to CAS

CASifying applications

In this section you will find instructions for adding CAS support to your web applications.

CAS is a service for providing authentication, answering the question: Who is this person?

CAS does not provide authorization. It does not answer the question: What can this person do?

Valid assumptions

Applications are free to make the following assumptions in relation to CAS.

  • User identifiers are unique - The identifier returned to an application from CAS will always uniquely identify a user.
  • User identifiers are un-changing - Changes in a user's status or name will not change their identifier.
  • The MemberOf (group membership attribute) is authoritative - Applications may use the MemberOf attribute to determine roles and authorizations. The values of this attribute are institutionally defined.

Invalid assumptions

Applications should not make the following assumptions in relation to CAS.

  • Authentication implying authorization - Authentication (and the receipt of a user id) does not imply that a user has any official status in relation to Middlebury College. Anyone can register for a visitor account (coming soon) that they can use to log in. Group-membership (MemberOf attribute) or a list of authorized ids should be checked to determine authorization within an application.
  • The user identifier implying meaning - Applications should treat the user identifier as an opaque integer with up to 10 digits. No meaning should be inferred by the value of the identifier.
  • Additional attributes exist and have been verified - The MemberOf attribute can be trusted to be authoritative. All other attributes -- such as FirstName, LastName, Email, etc -- may or may not exist and may contain values self-submitted by visitors.

Useful Groups

Every application has its own needs for access and the roles that should be given for various users. Some applications are completely open to public usage, others authorize access to anyone officially associated with the institution, and still others restrict authorization to very limited groups of users. Applications should use the MemberOf attribute to determine membership in groups. Some groups will contain just users that are officially associated with the institution, others will contain just visitors, and still others will contain a mixture of both visitors and institutionally-associated users.

For reference, here are some groups that applications may find useful for common cases:

  • CN=All Staff,OU=General,OU=Groups,DC=middlebury,DC=edu
  • CN=All Faculty,OU=General,OU=Groups,DC=middlebury,DC=edu
  • CN=students,OU=Students_By_Year,OU=Groups,DC=middlebury,DC=edu
  • CN=All LS People,OU=LS Lists,OU=Groups,DC=middlebury,DC=edu
  • CN=All LS Faculty,OU=LS Lists,OU=Groups,DC=middlebury,DC=edu
  • CN=MIIS Faculty,OU=Groups,DC=middlebury,DC=edu
  • CN=MIIS Staff,OU=Groups,DC=middlebury,DC=edu