Wow, this is really a great architeture, and it's only a tiny bit
different than what we were thinking. I especially like the way
multiphase challenges can be covered. I'll definitely implement a
clone of this system. Thanks, Mark!
Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
> ++1
>
> This design is similar to how PAM -- and other flexible authentication
> systems -- work. A lot of thought has gone into the design of such
> systems. Let's not reinvent the wheel here.
>
> Mark C. Chu-Carroll wrote:
>
> >I'm trying not to be too annoying with contributions about how our
> >project does things, but I think this might be useful to you.
> >We've just gone through a similar discussion in Synedra, with similar
> >constraints. In particular, we share the layering constraint where we
> >want no backward calls from the server to the client. At the same time,
> >we (like subversion) want full access through the network, and we don't
> >want to be transmitting passwords around *at all*.
> >
> >Our solution is object based, but I think there's a decent
> >pointer/structure based equivalent. And I think it meets the
> >constraints that Ben was talking about. And it's got one other big
> >advantage: you can add or alter authentication mechanisms without
> >requiring corresponding changes to client code.
> >
> >The idea is that we use "authentication components". An authentication
> >component is an object with a set of methods that can be used by the
> >client to prove that it has the appropriate credentials. In Java,
> >a trivial example is an authenticator for password authentication looks
> >like:
> >
> > class TrivialPasswordAuthenticator {
> > public void setUser(String user);
> > public void setPassword(String pass);
> > public RepositoryHandle authenticate();
> > }
> >
> >When a client connects, it can request from the server a list of
> >available authentication methods. If the client can handle any of the
> >methods provided by the server, then it requests an authenticator of
> >the correct type, and uses that to authenticate itself.
> >
> >This gets pretty nice when you consider challenge methods; an
> >HTTP digest style challenge can be done using a class with
> >a signature like the following:
> >
> >class HTTP_Authenticator {
> > HTTP_Authenticator(java.sql.Connection dbconn, String reposname);
> > Repository authenticate() throws PriviledgeException;
> > void setUserName(String name);
> > void setClientNonce(String cn);
> > void setURI(String uri);
> > String getURI(String uri);
> > void setOperation(String op);
> > String getServerNonce();
> > String getRealm();
> > void setChallengeCode(byte hashcode[]);
> >}
> >
> >
> >The client is expected to know the protocol for the authenticator. In
> >this
> >case, it can retrieve the information it needs to compute the challenge
> >result; and then it can provide the client nonce and the challenge
> >result
> >to the server before finally authenticating.
> >
> >Multiphase challenge can be done using an authenticator that returns a
> >second-stage authenticator from the "authenticate" call.
> >
> >So... A typical client interacting with this authentication method
> >would do:
> > Set<String> auths = getAuthenticators();
> > if (auths.contains("password")) {
> > PasswordAuthenticator pa = getAuthenticator("password");
> > pa.setUser(username);
> > .. prompt user for password ..
> > pa.setPassword(password);
> > RepositoryHandle handle = pa.authenticate();
> > ...
> > }
> >
> >Again, this method manages to provide solid authentication, with the
> >ability
> >to extend the set of recognized authenticators, but without requiring
> >changes
> >to old client. It should be fairly easy to provide this kind of
> >functionality
> >using closure style structs.
> >
> > -Mark
> >
> >
> >--
> >
> >Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
> ><mcc@watson.ibm.com>
> >*** The Synedra project:
> >http://domino.research.ibm.com/synedra/synedra.nsf
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> >For additional commands, e-mail: dev-help@subversion.tigris.org
> >
---------------------------------------------------------------------
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:34 2006