A couple of CoSign design and deployment questions

["Brett Lomas" <b.lomas@xxxxxxxxxxxxxx>]

Hi Kevin (and others :) ),

I have a few more questions about Cosign:

1. Why was it decided to store the cookies on disk? There are a couple of
reasons I ask this question. Linux/Unix default to only allowing around
65500 objects under a single directory. This in itself wouldn't normally be
a problem, but because the cosign and cosign service cookies (for the
daemon) are stored in one directory; this will fill up very quickly. If it
is suggested we go ahead with CoSign I will be suggesting to management that
we spend some time changing the storage to either a shared memory table
(because the cosignd and children have a shared parent) OR change it to use
a DB backend for storage (and it may also possible handle the replication to
other cosignd server databases). What do you think of these? Also having the
files named the same as the cookie is big security risk (in my opinion)...
it could possibly lead to exploits, although I am still doing my security
review and have not found a concrete example yet.

2. What size is your deployment at UM? Can you give me some stats, like the
hardware you are using and the number of authentications etc you service a
day. Only if this is not too much of an effort on your part, because I will
be stressing the application myself, I am just curious.

3. Have you successfully deployed CoSign to an n-tiered application? I
specifically ask because will needing the chosen implementation to be able
to SSO to our Cyrus IMAP server via Horde/IMP

Thanks very much for your time.


------------

Brett Lomas
Integration Architect
Information Technology Systems and Services
The University of Auckland
New Zealand

Phone:		+64 9 373 599 extn 86499
Mobile:		+64 21 757 096


-----Original Message-----
From: kevin mcgowan [mailto:clunis@xxxxxxxxx] 
Sent: Wednesday, 24 March 2004 12:51 a.m.
To: cosign-discuss@xxxxxxxxx
Subject: COSIGN: note: login form action="/"

This isn't really cosign, per se, but it came up in a discussion with 
someone trying to implement cosign yesterday so I thought I'd share 
with the group.  Those of you who've set up your own weblogin server 
(cosign.cgi, cosignd, monster) or read the weblogin server README 
probably know that, on Michigan's weblogin server, we do the following 
in the apache conf:

     1.  set up cosign.cgi as DirectoryIndex and make cosign.cgi's home 
DocumentRoot
     2.  set up AddHandler cgi-script  for files ending in .cgi
     3.  turn on ExecCGI for DocumentRoot

This has the effect of letting us give out:

      https://weblogin.umich.edu/

as our url without using mod_rewrite or similar tricks to hide the cgi 
from the url -- also without redirecting or modifying the URL in any 
way (e.g. never https://weblogin.umich.edu/cosign.cgi even though that 
would, of course, work perfectly).  This let's us use "/" as the action 
for our login form.

The problem we ran into shows up if you decide to move cosign.cgi down 
into a subdirectory, e.g.:

      https://weblogin.umich.edu/login/

If you use the same apache configs we do and then try to set the action 
of your login form as:

      action="/login"

you won't be able to submit your form (submitting will always just 
return you to the login screen).  This happens because apache gets the 
form's POST to a path that doesn't exist ( "/login" ) and redirects the 
request to "/login/".  As you might expect, though, this redirect 
happens as a GET, the POSTed information is lost, and all apache can do 
is display the DirectoryIndex.  This is pretty much exactly what 
happens when you ask for http://servername/docs when what you want is 
http://servername/docs/index.html  -- Apache redirects the url to 
handle the display of the DirectoryIndex.  As an interesting wrinkle, 
if you happen to use Lynx as your UA during testing you'll be asked if 
you'd like to go ahead and rePOST your information to the newly 
redirected URI presented by Apache. :)

The fix is setting your action to:

      action="/login/"

so the initial redirect won't happen and the POST can go where you, and 
cosign.cgi, expect it to.  Seemed like something folks might run into 
and find subtle.  Also it points up that our Apache config might not be 
the most obvious thing in the world.  I'd be happy to hear other 
suggestions for a setup that would allow URLs like the ones we use 
while maybe being more straightforward to operate or debug.

Kevin

                                       ... "In, as you say, the mud." ...