From cosign wiki

Contents 1 Cosign Authentication Process Overview 1.1 Use Cases 1.1.1 User Visits Weblogin 1.1.2 User Visits Service 1.2 Components 1.2.1 CGI 1.2.2 Daemon 1.2.3 Filter

[edit] Cosign Authentication Process Overview

[edit] Use Cases

There are two main use-cases for a Cosign session:

• A user visits weblogin before accessing a service
• A user attempts to visit a protected service directly

[edit] User Visits Weblogin

[edit] User Visits Service

[edit] Components

The main components of Cosign are the CGI, daemons, and filter. The Weblogin is comprised of the Cosign CGI and daemons, while the filter runs on a Cosign service.

[edit] 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 that a user logs into; this action ties the user's central login cookie to their session on individual application servers, such as web mail clients, web directory clients, or the UofM's CourseTools environment. The prototype CGI was built to use Kerberos V/GSSAPI to authenticate the user.

For more detailed information, see Cosign CGIs.

[edit] Daemon

The central daemon is responsible for maintaining the state of all Cosign sessions, including 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 that a user has accessed. The daemon has the ability to replicate its cookie database to multiply hosts, so that a failure of one server does not constitute a complete system failure. The daemon answers queries of user identity from both the CGI and the filter, and talks to other daemons via a replication protocol. The daemon was written in C and has knowledge of Kerberos 5 tickets.

For more detailed information, see Cosign Daemons.

[edit] 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 verifies that 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.

For more detailed information, see Cosign Filter.

--John DeStefano 11:58, 16 November 2006 (EST)