Difference between revisions of "CAS"
(Added tag: 'CAS')
|Line 55:||Line 55:|
Revision as of 10:36, 30 April 2009
Middlebury College uses the Central Authentication Service (CAS) developed by Yale and maintained by Jasig for single-sign-on to our suite of web-based applications.
Applications currently using CAS
Applications currently being converted to CAS
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?
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.
MemberOf(group membership attribute) is authoritative - Applications may use the
MemberOfattribute to determine roles and authorizations. The values of this attribute are institutionally defined.
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 (
MemberOfattribute) 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
MemberOfattribute can be trusted to be authoritative. All other attributes -- such as
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 LS People,OU=LS Lists,OU=Groups,DC=middlebury,DC=edu
CN=All LS Faculty,OU=LS Lists,OU=Groups,DC=middlebury,DC=edu