I’m working on adding support for authenticated service calls to RPC4Django built on top of Django’s user authentication. While doing this, I took a brief look around at how other projects implemented authentication for XMLRPC or JSONRPC. Without exception, they all implemented it such that the username and password was part of the RPC call like so:
|
1 2 3 4 5 6 7 8 |
from django.contrib.auth import authenticate def myAuthenticatedMethod(user, password, otherparams): # authenticate user user = authenticate(username=user, password=password) # verify the user is valid and has the appropriate permissions # perform method actions |
Some of them abstracted the actual username and password checking into a decorator, but in the end, the RPC call had the username and password in the parameters. It seemed bulky and out of place. This led to an analysis about authentication and authorization and what should be handled where. As a little spoiler, I don’t like the idea of sending the username and password in the RPC parameters one bit.
Authentication & Authorization
In applications, authentication is the process that confirms the identity of the user. Usually this takes the form of a login form, HTTP basic authentication, or something similar. Authorization is the process to determine whether the user has sufficient privileges to perform the specified action. This takes the form of permission checks based on the authenticated user. Therefore, authentication must come before authorization.
Fortunately, Django’s user authentication helps with both authentication and authorization. The authenticate method checks a username and password against the set of Django users and gets the user object if everything goes well. Once this user object is retrieved, permissions can be checked using the has_perm method. Django has a pretty easy way to create new permissions based on your application’s logic. Permissions have to be checked at the specific method level since permissions are closely tied to the application logic. I like the idea of abstracting much of it into a decorator though. The only remaining question is: where does the username and password come from?
An Example from the Real World
Why should every RPC method need to be specially written to accept the login credentials and authenticate the user? This makes the method only usable as an RPC method and not useful at all to the rest of the project which is bad for code reuse. Amazon s3, a commercial web service for storing files, is a perfect example of the proper way to authenticate and authorize users. With s3, the login information is contained in the HTTP header in a manner similar to HTTP basic authentication and in this way the request can be rejected earlier based on login credentials before the request even routes to the proper method requested. Permission checking, seeing whether the user is allowed to store new files for example, still needs to be done at the method level but at least the identity of the user is known.
Implementation and Demo
For RPC4Django, I’m proposing that authentication be handled at a higher level — with basic HTTP authentication for example. To illustrate this, I set up an https RPC4Django demo site that requires a username and password (rpc4django/rpc4django). The demo site requires that you accept a self-signed certificate. Using python, it is possible to send authenticated requests like so:
|
1 2 3 |
from xmlrpclib import ServerProxy s = ServerProxy('https://rpc4django:rpc4django@rpcauth.davidfischer.name/') s.system.listMethods() |
The next step is to modify RPC4Django to actually be able to specify permissions for specific methods and to actually log in the users. Expect a release this week.
I like this approach, in fact Qooxdoo people in their API also suposes this kind of authentication, see: http://demo.qooxdoo.org/current/apiviewer/#qx.io.remote.Rpc
To be consistent with Django I agree with you that user authentication should come in the HTTP header. The only risk I see in this is to be able to comunicate with non Python clients (Qooxdoo for me) and not make it just Python based.
Please let me know if I can help in any way.
@aaloy
This same type of authentication is supported by XMLRPC clients in at least Java and PHP and you are using it in Javascript. In addition, if the RPC client is on the same port, domain and protocol as the rest of your website, then once a user is authenticated in a browser session, all future requests for that session will contain the authentication information. This is why the simple Javascript JSONRPC client on the demo site’s method summary page still works. This is nice because you don’t even have to use a fancy Javascript library like qooxdoo. Just tie your Apache authentication to your Django user database and you’re done!
There really isn’t a whole lot of work to be done to add this authentication so I think I can handle it. However, I am always willing to accept a patch if you contribute something.
I’m leaning toward using the RemoteUserMiddleware, but that means making the authentication only compatible with Django 1.1+. However, this makes a lot of sense given that I’m using a server based authentication system. If in the future, I decide to support a session based authentication system, hopefully I can use a different middleware for that.