On Wed, 02 Dec 2009 19:13:58 +0000 Bill de hOra <[email protected]> wrote:
Bdh> Strong agreement. The login method should return an opaque token which Bdh> is passed on each call. If that messes up the API, that says more Bdh> about Thrift than the auth model. Slight disagreement on the semantics: this is not a stateless protocol anymore. Both the client and the server now need to keep track of these tokens and set expiration policies on them, throw token validity exceptions, etc. It's useful for sure, but not stateless. I'll put you down for stateless but you may want to comment further. So the question then flows into Robin's note: On Wed, 2 Dec 2009 11:59:57 -0800 "Coe, Robin" <[email protected]> wrote: CR> Once a connection is opened with credentials, then as long as I hold CR> that connection open, I shouldn't need to pass auth checks with CR> every transaction. Right, so you're on the stateful side. With Bill's vote we're 3-2 in favor of stateful. CR> On the other hand, if there was a way to use a token in lieu of CR> credentials, to provide SSO capabilities to any node, then I could CR> see their use. Checking whether a token exists in a local CR> collection would be much faster than having to pass through an CR> authentication/authorization framework. However, as there's no way CR> to ensure immediate consistency of tokens across all nodes, it's CR> probably not worth the effort of making Cassandra "token aware", CR> since an application would have to provide fall-back logic to CR> authenticate with credentials, if the token fails. So, tokens would CR> probably just add complexity without much benefit. The credentials are a map so it's trivial to add any credential (e.g. a GPG signed keyspace authorization request, Kerberos tokens, or Cassandra's own tokens). I think each AuthenticationBackend implementation should implement its own scheme (being careful not to overlap map keys), so certainly SSO is a possibility. Of course you should be able to have an AuthenticationOrBackend that combines two or more other backends, so it would for example try tokens first and then fall back to the slower credentials. The application wouldn't have to provide any fall-back logic. To accomplish this, though, the credentials will have to be returned by the login() method at the Thrift level. I'll make the change. Ted
