How It Works.
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
In .pdf, here are the two most common scenarios for
User visits weblogin first:
User visits service first:
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.
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.
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.
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 Cosign Presentation
Umich response to Internet2 Middleware Initiative's WebISO
Web Application Agent Questionnaire ( early 2003, but still
relatively applicable )
History of cookie-based web authentication at the
University of Michigan and description of Cosign