HTTP/CLI Authentication

[Matthew Earl]

Allow authentication over HTTP using standard HTTP authentication. I'm not sure how authentication would be performed server side (ie. what would be done with the username and password to determine if the user is who he says he is). Presumably LDAP, although I can't find a builtin/twisted LDAP module.

Also a scheme which means CLI commands can be used without having to enter a password each time. Possible thoughts on this:
  1) Store password in a chmod 600 plain-text (or some obfuscated form). Bad for security reasons, but compatible with HTTP auth above.
  2) Store a cookie in a chmod 600 plain-text file. The cookie is generated (randomly) by successfully authing with some other method. The cookie can be included with requests, which the server authenticates by looking up in a DB of (hashed?) cookies. This is similar to the scheme many websites use. Susceptible to the cookie being sniffed on the wire. Can provide a "logout" option to revoke the current cookie.
  3) Same as above, except the cookie is hashed with the message content and maybe some sort of timestamp? Avoids the cookie sniffing issue, but has extra complexity, in particular defining a canonical form for the message to be hashed. May be difficult as the URL is represented differently on the server side vs the client (indeed, Apache rewrite rules may rule out this scheme entirely.)
  4) OAuth type system. AFAICT this is similar to the cookie scheme, except there's the possibility to have multiple cookies, and for them to be explicitly managed to e.g. permit/allow certain abilities, or revoke entirely.
  5) OpenPGP based authentication. This way the "authentication token" is only known to the client. Equivalent (I think) to SSH'ing using PKA using files in ~/.id_rsa{,.pub}.

[Matthew Earl (matthew-earl)]

Personally, I like option #2. #1 is an obvious security no-no, #3 - #5 seem overkill (ie. adding UX and code complexity for little benefit.)

[Martin Morrison (isoschiz)]

I'd have thought Oauth would be the way to go, especially if we can get a generic helper plugin that supports it, and that other plugins can use.

How the identification is done needs to be pluggable as well (ie how we map a username to a JID). Ideally the authentication would be too, with LDAP as an option.

In the past, we've used ProcessProtocol and the ldap CLIs to do the auth. I once found a library (I think called ldaptor) that was a twisted library for direct access.

[Matthew Earl (matthew-earl)]

Do you mean use the actual OAuth 2 protocol, or something OAuth like? Can you expand on what the generic helper plugin would provide and how other plugins would use it?

Also, how would pluggable authentication work? Would there be a central page where you can log in with multiple methods (one per plugin) and from there you're provided with a cookie that authenticates you on subsequent requests?

[Martin Morrison (isoschiz)]

I was suggesting something OAuth-like - OAuth itself if that turns out to be easy enough.

For the Auth helper plugin, I anticipate it providing some helper classes/functions to other plugins to register an "Authenticated Resource" with the HTTP Interface plugin. It would then intercept cookies/HTTP Basic Auth information, verify it against its database/an auth backend, and then provide the logged in user's JID to the plugin whose page was being requested. Further, it would provide its own pages for users to manage their authentication mechanisms (OAuth cookies).

For the pluggable authentication, I just mean a set of plugins with a common API that can go to different backends. We'd want an LDAP one, but could also add a PAM one, or a local SQL DB of username/passwords. The general Auth plugin would request login from each of the installed login mechanisms until one passed.

I believe we already have most of the code for the LDAP and Authenticated Resource elements of the above lying around. Your remote plugin also has the basics of an OAuth-style cookie mechanism, so this is hopefully not too much work.