authentication architecture.

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.

Here are the parameters of the problem:

   * The callers of any RA (Repository Access) library need to provide
     a structure that represents who's doing the access. It's up to
     the RA layer to actually *do* the authentication (and
     authorization). It's up to the caller to provide the necessary
     authentication info.

   * If new RA schemas are written, or new RA layers are written, it's
     inevitable that every top-level client in the world will need to
     be tweaked and rebuilt to support them -- to *some* degree.

     The issue here is that an RA library cannot directly prompt the
     user for information -- like a password. So the top-level client
     will need to "learn" about each RA library's authentication
     needs. However, we'd like as little code churn as possible. For
     example: if ra_foo needs information X to authenticate, and
     somebody writes a new ra_bar module that needs the same
     information, ra_bar should be able to make use of the fact that
     the client-side libraries *already* know how to get it.

Here is what we're going to do:

* 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.)

* all svn_client_*() routines now take a new argument: a 'hook'
  routine from the command-line (or GUI) client.

   * when svn_client_*() fetches an RA library appropriate to the URL
     schema, it will get back a flag state. This flag-state indicates
     which fields are needed within the user structure by the
     particular RA library.

   * libsvn_client now attempts to fill in every user_t field it can.
     (for example, it can easily fill in a Unix UID field.)

   * if libsvn_client can't fill in all the fields, it "kicks" the
     user_t structure up to its client caller (using the hook routine)
     and then the client finishes the job. (for example, prompting
     the user for a password, reading a config file, etc.)

   * the user_t object is now passed (along with the URL) to ra->open().

         * the RA library does whatever authentication/authorization
           it wants under the hood.

         * the RA library (presumably) stashes the user_t object in
           the "session baton" returned to libsvn_client.

   * libsvn_client now goes on and uses the RA session baton as usual.

---------------------------------------------------------------------
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