Database locked

= Cosign Daemons =
Cosign has two daemons: ''cosignd'' and ''monster.'' <tt>cosignd</tt> is responsible for implementing the server side of the Cosign protocol, as well as maintaining the Cosign cookie database and, optionally, replicating the <tt>LOGIN</tt>, <tt>REGISTER</tt>, and <tt>LOGOUT</tt> commands to all other <tt>cosignd</tt>s in the server pool. <tt>monster</tt> is responsible for deleting old cookies (login or service) as well as corresponding Kerberos tickets from the database. <tt>monster</tt> also optionally replicates the logged in/out state and last update time for all of the login cookies in its database via the <tt>TIME</tt> command.

== cosignd ==
<tt>cosignd</tt>, also known as the central daemon, is the server-side implementation of the Cosign protocol (see [[#Protocol|Protocol]]). 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. In addition, 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 multiple hosts, so that a failure of one server does not constitute a failure of the entire system. The daemon answers queries of user identity from both the CGI and the filter and communicates with other daemons.

== monster ==
<tt>monster</tt> serves two separate functions. In all cases, it is the mechanism by which old cookies and tickets can be deleted when they are no longer needed. In addition, in a replicated cosign environment, <tt>monster</tt> can be used to propagate the time stamps and state of the login cookies. If replication is activated, monster retrieves the host information for the other hosts in the Cosign pool and opens an SSL connection to the <tt>cosignd</tt>s on all of the other Cosign hosts.

<tt>monster</tt> sleeps for <tt>timestamp-pushing-interval</tt> (120 seconds) between successive passes through the cookie database. <tt>monster</tt> stats each login cookie, checking to see if it is:<br/>
a) past the <tt>idle-time-out</tt> (4.5 hours, which is idle time + grey window from <tt>cosignd</tt>, + the usual <tt>loggedout_cache</tt> time in <tt>monster</tt>),<br/>
b) the <tt>hard-timeout</tt> (12 hours), or <br/>
c) if the cookie state is already logged out and the cookie is past the <tt>loggedout-keep-time</tt> (2 hours).

If the login cookie is past any of these three timeouts, the cookie and any corresponding Kerberos tickets are deleted. When <tt>monster</tt> encounters a service cookie, it looks up the corresponding login cookie and checks for timeouts, as specified above. If any are encountered, the daemon deletes the login cookie as well as the service cookie. If the service cookie’s corresponding login cookie has already been deleted, the service cookie is also deleted.

== Local Cookie Stores ==
The daemon and filters use the following format for the local cookie store:<br/>
'''Filter'''<br/>
'''i''' ''IP address''<br/>
'''p''' ''principal (user name)''<br/>
'''r''' ''realm (first factor)''<br/>
'''f''' ''all factors''<br/>
'''k''' ''kerberos ticket path (optional, if built in)''

For example:
<pre>i66.93.92.59
ptestuser
rUMICH.EDU
fUMICH.EDU mtoken
k/ticket/EjAP2EqDy-5</pre>

'''Daemon'''<br/>
'''v''' ''version''<br/>
'''s''' ''state''<br/>
'''i''' ''initial IP address''<br/>
'''j''' ''subsequent IP address ( same as initial if no change)''<br/>
'''p''' ''principal (user name)''<br/>
'''r''' ''factor(s)''<br/>
'''t''' ''time data was stored, in seconds, since 1970''<br/>
'''k''' ''kerberos ticket path (optional, if built in)'' 

For example:
<pre>v2
s1
i141.213.147.32
j141.213.147.32
ptestuser
rUMICH.EDU
t1150894952
k/ticket/EjAP2EqDy-5l</pre>

<div id="Protocol"></div>
== Protocol ==

To be continued.