This is a somewhat simplified visual representation of Cosign authentication process and information flow. Time flows from the top of the diagram to the bottom. 'Weblogin' is the central cosign server, 'user' is the web user, and 'service' is a cosign-protected web server.

In .pdf, here are the two most common scenarios for initial authentication:

User visits weblogin first: cosigncase1.pdf
User visits service first: cosigncase2.pdf

Here's a brief overview of the components. The CGI & Daemon make up "Weblogin" in the diagram. Filter is the cosign part that runs on "Service" in the diagram.

cgi

The central cgi is responsible for logging users into and out of the central cosign server. It is also responsible for registering each service a user logs into - this action ties the user's central login cookie to their session on individual application servers such as our web mail client, web directory client, or CourseTools environment. The prototype CGI was built to use Kerberos V/GSSAPI to authenticate the user.

daemon

The central daemon is responsible for maintaining the state of all cosign sessions. This includes keeping track of which users have logged in, logged out, and idle timed out. This also means the daemon keeps track of all of the service cookies that represent the authenticated web applications a user has accessed. The daemon has the ability to replicate its cookie database to multiply hosts, so a failure of one server does not constitute a failure of the system. The daemon answers queries of user identity from both the cgi and the filter, and talks to other daemons through a replication protocol. The daemon was written in C and has knowledge of Kerberos V tickets.

filter

The filter resides on an application server, and is not part of the centralized cosign infrastructure. The filter is responsible for determining which areas of a web site are protected by cosign and which are not. If a user attempts to access a protected area, the filter assures the user is authenticated, and obtains their username, authentication realm, IP address, and optionally a Kerberos ticket. This information can then be used by other authorization mechanisms to make further access decisions. The prototype filter was written in C for Apache 1.3.x.

Leveraging Guest Accounts for Ubiquitous Web Sign-On System Acceptance - conference presentation from Educause 2005.

Educause 2005 Cosign Presentation

The Quest for Web Single-Sign On at the University of Michigan - poster presentation from Educause 2003.

Educause 2003 Cosign Presentation

Umich response to Internet2 Middleware Initiative's WebISO Web Application Agent Questionnaire ( early 2003, but still relatively applicable )

umich.txt

History of cookie-based web authentication at the University of Michigan and description of Cosign enhancements.

proposal.rtf