Re: [Libvir] PATCH: RFC supporting SASL authentication

On Thu, Oct 18, 2007 at 10:44:57AM -0400, Daniel Veillard wrote: Having the client export its auth types isn't really neccessary, since the server only supports a single primary auth type for any given socket. The SASL auth type, does have many sub-auth types - eg GSSAPI, PLAIN, OTP, etc and that's what the 'list mechanisms' called below provides info about. The client asks server for all SASL mechanisms that are allowed - it then chooss the best one it supports. If we need this for the primary libvirt auth types too, I'd change the wire protocol a little, so that when sending the REMOTE_AUTH code, we would send back a list of allowed primary auth types. The client can then invoke the RPC call for whichever one they support. This would let us support both PolicyKit & SASL on the same socket, which could be nice i guess. I'm not sure what you mean here ? The whole remote session, takes place over a TCP socket. We are requiring authentication upfront, before allowing the virConnectOpen call. Once the client closes the socket, they have to open a new one & start the whole procss from scratch. Both the client & server cope with the other end dropping the connection in the middle of a handshake by just cleaning up their state. Well if we registered a global function virConnectCallbacks(...) to register a set of callbacks that would be sufficient. The callbacks would be guarenteed to always execute in the same thread as the virConnectOpen() call itself. So we'd just have to document that you should make sure that the callbacks are able to run in parallel - ie multiple threads can be in virConnectOpen calls at once. Threading isn't really the thing to worry about here. The hard bit is actally designing what data goes in & out of the callbacks. SASL has a pretty large list of possible callbacks. I listed a couple here http://www.redhat.com/archives/libvir-list/2007-January/msg00024.html but now I've looked at SASL more closely there's many more to consider & I think I can do a better job than my original proposal. Well its really a SASL implementation detail. There is a way you can specify a maximum network packet size you're prepared to accept. I need to check whether this appllies to the initial handshake, or just the post-handshake session encryption. Yep, not sure what todo here really, aisde from a local group file. Why, it just lets you do --with-sasl=/opt/sasl Yes, it assumes people install the libraries & headers into the same prefix, but frankly that's not unreasonable. *Many* different callbacks. Rather than listing them here, take a look at /usr/include/sasl/sasl.h - search for 'struct sasl_callback' - following the struct definition are many callback function signatures. Also look at the 'sasl_callbacks' many page. This is specifically for server side calbacks. These deal with stuff like pluggable password checking API, and an authorization checking API. There is separate client side callbacks elsewhere, but I'd probably not use them. Instead I'd go for what SASL calls 'interactions'. Basically the 'step' API will fail & give you back a list of interactions that are needed. The advantage of this is that you can feed these back to the client app all in one go, rather than one-at-a-time. This makes is practical to build a UI prompting for all data at once. This is server side & in fact the username field here is rarly used. The purpose here is to allow you to filter the list of authentication schemes given back to the client based on client's username. Trouble is you can't really trust the username at this point since we've done no auth, so it is of limited use. The docs say you rarely need to worry about this field, just leaving it NULL. [snip] There is alot of line noise there with the error handling, but bascialy it comes down to -> sasl_client_new -> Run the REMOTE_PROC_AUTH_SASL_INIT rpc call -> sasl_client_start -> Run the REMOTE_PROC_AUTH_SASL_START rpc call repeat until authenticated: -> sasl_client_step -> Run the REMOTE_PROC_AUTH_SASL_STEP rpc call Each of teh rpc calls basically ends up doing the equivalent SASL func on the server eg, sasl_server_new, sasl_server_start and sasl_server_step So it is pretty symmetric in sequence of calls. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|