[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: authentication architecture.

From: Justus Pendleton <subversion_at_ryoohki.net>
Date: 2001-07-26 20:29:01 CEST

Ben Collins-Sussman writes:

> I'm filling in the list on an authentication architecture we'll be
> using for upcoming M3. It's about as generalized as it can be.

I don't if you've already seen this or not but isn't this pretty much the
problem that they try to solve with:

http://www.kernel.org/pub/linux/libs/pam/pre/doc/current-draft.txt

> The issue here is that an RA library cannot directly prompt the
> user for information -- like a password.

But the client only needs to support four or five methods and the RA library
can indirectly prompt for whatever information it desires. I'm not sure I
see a huge difference between directly prompting and indirectly promting
only one step removed.

> * create a transparent svn_ra_user_t structure.
>
> This structure contains the *union* of all authentication data
> needed by all RA implementations. (There's no way around this.)

I don't follow why there is no way around this, maybe you can explain?
Wouldn't some opaque shared secret (that doesn't contain possibly sensitive
authentication data) work just as well? That way potentially sensitive data
isn't just sitting around in memory and isn't being sent across the wire
with every action requested? And that way you don't need to stick a
potentially large svn_ra_user_t structure in the baton, only about 20 bytes
of fingerprint.

Justus

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:33 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.