Protocol

Goal

To determine the requirements of the CAS community with regards to a protocol for the next generation of CAS. This document should help us identify potential existing standard protocols that may meet our needs, protocols that almost meet our needs that we can work with the community on, protocols which do not meet our needs, or possibly to start a working group to create a protocol that meets our needs.

Note that while we are identifying a protocol that meets our needs, that does not preclude CAS from supporting other protocols that implement some subset of the requirements for interoperability purposes with existing applications.

Scope

The scope of this document is to create a single sign on protocol that works with both traditional web applications, and non-web applications that access web resources (i.e. iPhoto accessing Facebook API). This document does not attempt to describe how you should authenticate someone (i.e. passwords, etc.). This page should capture the high level requirements but not the details of the protocol (i.e. value A is passed back as part of parameter B, etc.)

General Requirements

• The protocol needs to be easy to read, understand, and parse by both humans and machine. If its unreadable by humans, its too hard to learn. If its a pain to parse by machine then we're making it too difficult to implement clients.
• The protocol should be extensible. Just like the CAS architecture has plugin points, the protocol should offer ways to add your needed data in (i.e. we don't define specific attributes that can be returned as XML, but provide the point where you put in your attributes, along with a way for describing the attributes such that a machine can parse them).
• Support for web applications and non-web applications.
• Expose API for using protocol via standards such as REST and WS-*

Logon Requirements

• Ability to opt-out of an already existing single sign on session. CAS1&2 do this by the renew=true parameter while OpenID has an extension that allows you to specify last authentication time. Another potential is requiring re-auth on change of IP address.
• Ability to specify authentication method and/or LOA. OpenID has an extension to return LoA.
• Ability to notify service what attributes to release to allow person to approve/disprove. Protocol should also allow for "trusted" applications not to have to specify this stuff and have it configured server side.
• Offer single sign on for both web and non-web applications. Combination of OpenId+OAuth can offer this.
• Ability to be warned when signing in to pages (i.e. CAS's WARN cookie)
• Ability for application to merely determine if session exists (i.e. CAS's gateway=true)
• If a single token is sent back to an application it should not be sent via Request parameters. The original request url should be preserved. Headers should be used.
• Logon needs to work across domains.

Validation Requirements

• Ability for an application to either ask the CAS server to validate a ticket identifier, or it has the ability to self validate via temporary exchanged keys.
• Ability to send back meta data about authentication, as well as attributes about user
• Ability to anonymize or pseudo anonymize the user

Proxying/Delegation

• A service should be able to access another service on behalf of the user. In some cases this may be explicitly authorized in the case of applications that can use something like OAuth (i.e. iPhoto accessing your Facebook API) or implicitly like a institutional portal accessing your mail to display it in a portlet.
• Should be a method to pass attributes to delegated applications

Logout Requirements

• Ability for application to determine if it wants to participate in single sign out or not
• Logout destroys all information associated with SSO session.
• Ability to specify a return url to be displayed or a url to redirect to after logout