[Clipart] XML hierarchies, the DMS, daemons, and Debian

[Bryce Harrington]

On Tue, 12 Oct 2004, Jonadab the Unsightly One wrote:
> I really ought to get myself a spare Pentium/90 for playing with, so I
> can have a system to install various distros on without having to fool
> with my main workstation.  I want to do that anyway, so I can
> experiment with BSD, and it would let me mess with Debian too.

dealsdepot.com 

> >> The DMS is going to be called by various code, most of it running
> >> in a CGI interface (or later maybe mod_perl).  The code that calls
> >> it is going to get auth credentials from a user _once_ and then
> >> send the user a magic cookie, which the browser will store.  The
> >> cookie shouldn't contain the auth credentials themselves for
> >> security reasons, so subsequently something will look up the cookie
> >> in a database or something to see that it's valid and which user it
> >> represents.  The DMS could serve as the "database or something"
> >> that everything looks up the cookie in.  Or that could be separate
> >> from the DMS.  Not sure which approach is better there.
> >
> > I was planning to investigate auth for SOAP daemons a bit today but
> > didn't get a chance.
> 
> I don't know anything about SOAP, so I can't comment meaninfully here.

It's pretty transparent; there isn't much you need to know from the
clientside.  Here, try this:  (Install SOAP::Lite, then run this)

#!/usr/bin/perl -w
use SOAP::Lite;

my $soap = SOAP::Lite
    ->uri('http://www.openclipart.org/Document/Manager')
    ->proxy('http://www.openclipart.org:8012/',
            options => {compress_threshold => 10000}
            );

my $dms = $soap
    -> call(new => 0)
    -> result;

my $result = $soap->query($dms);

foreach my $row (@{$result->result}) {
    next unless $row;
    print $row, "\n";
}

That calls the dms on freedesktop.org and pulls down the ID numbers for
all the documents currently loaded there.  I've omitted the error
handling for brevity, but look at ls_docs in dms/scripts for the
complete script.

(Once I figure out how we want to store metadata I can return all that
info as well, so we will be able to print a complete list.)

> There's no real need for the DMS to trust the calling code if we store
> the auth info in the RDBMS; then it can look up the cookie itself
> easily.  The calling code just passes it the same cookie the user's
> browser sends.

I'm going to try working on setting this bit up tomorrow.

> We have one trusted script that handles logging the user in.  The
> login script has to have write access to the cookies table in the
> RDBMS, but everything else only needs read access to the cookies
> table.  The login script is also the only thing that needs to be able
> to check a user's password, so it could have a private passwords table
> that only it has any access to at all.
> 
> So when login.cgi (or whatever) is called with no input (i.e., no
> query string and no POST input), it sends a blank login form, which
> points back to the same script; when the user submits the form, the
> login script checks the password and authenticates the user.  If the
> username and password are a match, it creates a thirty-byte random
> string of alphanumeric characters, which it sends to the browser in a
> cookie; it _also_ creates a new entry in the cookies table keyed on
> the _same_ thirty-byte string; this record will also contain the
> user's username and possibly other info, such as IP address, an
> expiration timeframe, and so on.

*Nod* Sounds sort of similar to how Apache::AuthTicket works (which we
use at work), except that it issues tickets, which expire after a
predefined time and require re-authentication.  This way if you log in
at a public terminal or something, the authenticated cookie doesn't
remain valid forever.

> In addition to the login script, there would be one other secure
> script that would use the same credentials as the login script to get
> write access, and that's the script that registers users in the first
> place; it would presumably ask the user for a proposed username, other
> information we want, and an email address; it would create an entry in
> the users table but with a "notenabled" field set, and it would send
> the user an email with a magic URI pointing back to the same script
> with a query string containing a magic token that matches the magic
> token embedded in the notenabled field; on receiving this token, the
> script would then enable the user account, and the user can then log
> in any time using the login script.  This guarantees we have a working
> email address (initially) for every user, but users can create their
> own accounts without any manual intervention.  If a problem with bots
> develops we could put a CAPTCHA in place, but that will *hopefully*
> not be necessary.

It would probably be worth looking at how Mantis does it, because it
probably already has this stuff implemented and we could just piggyback
on it.  (From my previous experience setting up the aforementioned
ticket system, they're a pain in the ass to debug.)

> The only security issue here now is that the cookie can be sniffed by
> a man-in-the-middle attack, but that still only allows the attacker to
> impersonate the sniffed user, and only until the user logs in again,
> at which point the login script will delete any previous cookies
> belonging to the same user.  The only way to solve that one is for the
> whole site to be https, which I think is really unnecessary for us.

> The only question left is whether the login script should be https; if
> it's not, a man-in-the-middle attack could sniff an actual password.
> Whether we consider that a likely enough or serious enough threat to
> worry about is an open question.

I doubt it's much of a threat, but we probably ought to do it right.
I agree that https for the whole site is overkill, but the login form
itself should be kept secure, even if only for good practice reasons.

> > However, I've got a plan here.  One of the things I was looking for
> > when I picked out mantis was its authentication system.  Having
> > developed auth systems before, I really didn't want to have to do it
> > yet again.  Most bug trackers have an auth system built into them,
> > for obvious reasons, and I figured regardless of what we did for
> > auth, we'd want to tie it in with bug tracking, so users wouldn't
> > need separate accounts for submitting bugs from doing other stuff.
> >
> > What I would suggest is this - log into freedesktop.org and browse
> > through the mantis source code to learn how it does the
> > authentication.  I think the mysql account info is listed there; use
> > that to log into mysql and look directly at the database if you're
> > comfortable doing that.  
> 
> I'm comfortable with MySQL.  Mantis is what, PHP?  I can probably read
> PHP well enough to figure out what it's doing.

Yup.

> > Doublecheck that it produces login cookies that we can reuse (I
> > believe its a ticket-based system iirc.)
> 
> Ticket-based is good.
> 
> I'll try to look into this, after I get the other thing done I'm
> working on.
> 
> If this will work, we might even be able to get out of creating a
> login.cgi, since we could just point to the Mantis one.  Maybe.

Yup, that's the hope.  Let us know how it looks.  :-)

Bryce