Hi,
> From: Ben Collins-Sussman [mailto:sussman@collab.net]
> Sent: 14 September 2001 00:06
>
> Gee, like we need another huge discussion. :-)
*grin*
> There's a laundry list of things to do re: rewriting the way we do
> authentication on the client-side. (IOW, deciding how the RA
> libraries, libsvn_client, and the client app all work together to
> authenticate against a server.)
>
> I've rewritten the issues listed in bug #456 below. All of them are
> very easy to do, except for the last two. I specifically need to ask
> Greg how the heck things are working, or how they should work.
>
> Greg, Joe, can you guys talk about the last two issues?
Well, I'm not Greg or Joe, but I am going to give you some feedback.
> ------------------------
>
>
> Subversion authentication system rewrite. (#456)
>
> Wishlist
> ========
>
> A. new RA vtable sequence: put back open(). [EASY]
>
> RA->open (URL, callback, [...])
>
> ...callback can be a way of storing a tmp file in WC.
>
> authenticator = RA->get_authenticator(method)
> session_baton = svn_client_authenticate(authenticator)
>
> ... drives the authenticator object.
>
> B. RA session opened by app, not in libsvn_client. [EASY]
>
> Have [cmdline/main.c] open the RA session, and all of the
> svn_client_ routines *take* an authenticated session_baton.
>
> This will make things better for GUIs or shells, or anything that
> plans to execute more than one subcommand before exiting!
Yes, this would be very good.
> C. Improve auth-method selection [EASY]
>
> -- auth-method as optional commandline switch
>
> Use a single switch that takes a string: e.g. --auth="ssl"
>
> -- else: keep trying all available methods until they all fail.
> Cache info from one attempt to the next if possible.
This is unneeded. The server _tells_ you what it wants. OpenSSL has a
nice callback that is invoked if client auth is wanted.
> D. Prompts [EASY]
>
> -- display the method being used
>
> -- display a 'default' username if available
>
> -- prompt callback should take an array of prompts
I think the prompt callback would be more general. It is more a
'get auth info' callback. If auth info is cached, return the
cached info. If not, prompt.
For ra_local I think there never should be a callback. The current
username (looked up using uid on *nix) is what is used, period. Otherwise
it only adds up to the security problems that ra_local already has.
IMO local users should be trusted*, but we shouldn't make it that easy
to fake another users identity.
*) Or should I say: 'you should be able to trust local users'?
> E. Push vs. Pull models. [HARD]
>
> The current system pre-emptively requests info, then "pushes" it
> at the RA layer. This is odd, given that Apache typically makes
> a challenge and then "pulls" the info. As a result, the info is
> effectively being cached in the session_baton until Apache pulls
> it from there.
>
> So, it would be nice to switch the whole client/user-interface to
> work with the "pull" model too. One of the main benefits of this
> is that failed authenication can be detected *immediately*;
> right now failed authentication is simply ignored during
> checkout, and isn't discovered until a commit fails later on.
The latter is badness. On failure of cached auth info*, we should reprompt.
This could also happen if the admin changes your password, so it is
pretty essential. I'd say, use the pull method always. This works
well for ssl too.
Btw, this isn't so HARD. Maybe not EASY, but MEDIUM may even be too
much. Neon and OpenSSL have already done a lot of the groundwork for
this. Neon needs some extra callbacks for ssl, but when that is in,
it is pretty straightforward.
*) On the filesystem in the WC, I'm not reffering to cached info in the
session baton.
> F. Method negotiation? [HARD]
>
> Can the RA library (running client-side) 'discover' what methods
> are supported by the server?
>
> Ideally, this list of methods returned to the client should be
> dynamically discovered, rather than being a static list, as
> it is now.
This is very hard to do and IMHO not needed. In case of ra_dav, the
server tells you what it wants on demand. If the client can't handle
that demand, too bad, we fail. The client should have a list of auth
callbacks (one for every type), the default could print a failure
message and bail out. Real callbacks handle getting info from
cache/prompting.
Sander
---------------------------------------------------------------------
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:41 2006