|  | 
      
        |  
 
    
    | 
    
        |  | Cosign Overview |  
        | 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
		server.
	     
		  
 
		 
	     
         
            
	    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.
	     
            
	     cgiThe 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. 
            
	     daemonThe 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. 
            
	     filterThe 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 
 
             
         |  |  |