cosign wiki:CosignDaemons
From cosign wiki
Contents |
Cosign Daemons
Cosign has two daemons: cosignd and monster. cosignd is responsible for implementing the server side of the Cosign protocol, as well as maintaining the Cosign cookie database and, optionally, replicating the LOGIN, REGISTER, and LOGOUT commands to all other cosignds in the server pool. monster is responsible for deleting old cookies (login or service) as well as corresponding Kerberos tickets from the database. monster also optionally replicates the logged in/out state and last update time for all of the login cookies in its database via the TIME command.
cosignd
cosignd, also known as the central daemon, is the server-side implementation of the Cosign protocol (see 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
monster 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, monster 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 cosignds on all of the other Cosign hosts.
monster sleeps for timestamp-pushing-interval (120 seconds) between successive passes through the cookie database. monster stats each login cookie, checking to see if it is:
a) past the idle-time-out (4.5 hours, which is idle time + grey window from cosignd, + the usual loggedout_cache time in monster),
b) the hard-timeout (12 hours), or
c) if the cookie state is already logged out and the cookie is past the loggedout-keep-time (2 hours).
If the login cookie is past any of these three timeouts, the cookie and any corresponding Kerberos tickets are deleted. When monster 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:
Filter
i IP address
p principal (user name)
r realm (first factor)
f all factors
k kerberos ticket path (optional, if built in)
For example:
i66.93.92.59 ptestuser rUMICH.EDU fUMICH.EDU mtoken k/ticket/EjAP2EqDy-5
Daemon
v version
s state
i initial IP address
j subsequent IP address ( same as initial if no change)
p principal (user name)
r factor(s)
t time data was stored, in seconds, since 1970
k kerberos ticket path (optional, if built in)
For example:
v2 s1 i141.213.147.32 j141.213.147.32 ptestuser rUMICH.EDU t1150894952 k/ticket/EjAP2EqDy-5l
Protocol
To be continued.
