php and java json-rpc implementations compatible and with ssl support

Question

I'm working for a company and they require me to code an Android application that will handle sensitive data stored on a centralized database (MySQL), so I need to code a web service to communicate the Android app with the DB, and since in that connection will flow sensitive data I need to use a secure connection for that.

So, I decided to use json-rpc for the commucation, that's why I'm looking for two json-rpc implementations: the server-side in PHP (actually the hosting that they have is running PHP 4.3), and client side in Java (Compatible with Android) compatible between them and with SSL support.

Answer 1

I'm sure someone might make some suggestions, but this probably isn't the best venue to get help with library selection.

If, on the other hand, you ask concrete questions about certain libraries/implementations you might get intelligent answers. A common problem with that approch is that the asker doesn't know what questions to ask! (And that leads to re-inventions of wheels and commonly, poor decisions around security).

The JSON-RPC (1.0/1.1/2.0) group of protocols are extremely simple. There are hundreds of PHP implementations. I don't know much about evaluating Android libraries but this prior SO question gives a suggested client-side implementation for Android.

I'll primarily deal with the server-side part of your question by giving you concrete answers you can ask about a particular implementation you might be evaluating.

Considerations for the server-side PHP JSON-RPC implementation:

1. How will you handle transport authentication?
2. How will you handle RPC-method authorization?
3. How will you handle transport security?
4. Will you need to handle positional/named/both style method arguments
5. Will you need to handle/send notification messages?
6. Will you need to handle batch requests? Will you need to send batch responses?
7. How does the PHP implementation behave under a variety of exception/warning conditions?
8. How does the PHP implementation advise against or mitigate the PHP array set/list duality?
9. Will you need to implement SMD?
10. Will your web-service also need to perform other HTTP-level routing? (e.g: to static resources)

---

How will you handle transport authentication?

Assuming you use HTTP as the transport-layer protocol, how will you authenticate HTTP requests? Will you use password/HTTP-auth/certificate/SRP/other authentication? Will you continue to trust an open socket? Will you use cookies to extend trust after authentication?

These aren't really JSON-RPC related questions, but many server-side implementations make all sorts of assumptions about how you'll do authentication. Some just leave that entirely up to you. Your choice of library is likely be greatly informed by your choices here.

How will you handle RPC-method authorization?

You might decide that once a user is authenticated that they're allowed to call all exposed methods. If not, then you need a mechanism to allow individual users (or groups of them) to execute some methods but not others.

While these concerns live inside the JSON-RPC envelope, they're not directly addressed by the JSON-RPC protocol specifications.

If you do need to implement a method-"authorization" scheme, you might find that some server implementations make this difficult or impossible. Look for a library that exposes hooks or callbacks prior to routing JSON-RPC requests to individual PHP functions so that you can inspect the requests and combine them with authentication-related information to make decisions about how/whether to handle those requests. If the library leaves you to your own devices here, you'll likely have to duplicate lots of user/method checking code across your JSON-RPC exposed PHP functions.

How will you handle transport security?

Assuming you use HTTP as your transport-level protocol, the obvious answer to this is TLS. All the usual SSL/TLS security concerns apply here and many SE/SO questions already deal with these.

Since you control the client-side implementation, you should at least consider:

• Choosing a strong cypher & disallowing poor cyphers
• Dealing (or not dealing!) with re-negotiation in a sane way
• Avoiding known-problematic implementations/features (e.g: OpenSSL 1.0.1-1.0.1f, heartbeat[CVE-2014-160]).

Will you need to handle positional/named/both style method arguments

Some JSON-RPC server-side implementations prefer that the params argument of the JSON-RPC envelope looks like params: [412, "something"] (positional), while others prefer that the params argument of the JSON-RPC envelope looks like params: { "type": "something", "num_events": 412 } (named). Still others can handle either style without issue. Your choice of client & server libraries should be informed by this issue of 'compatibility'.

Will you need to handle/send notification messages?

Notification messages are sent by the client or the server to the opposite party in order to communicate some updated/completed state over time. The sending party (ostensibly) shouldn't expect a response to a "notification" message.

Most JSON-RPC implementations use HTTP(S) for their transport protocol; as HTTP doesn't implement bi-directional asynchronous communications, you can't prooperly implement "notification" messages.

As your client side will be Android, you could use plain JSON text over TCP sockets as the transport protocol (rather than HTTP); as TCP does allow bi-directional asynchronous communications (once the socket is established), then you can properly implement "notification" messages.

Some libaries implement client-to-server notifications over HTTP transport by enqueing notification messages and then piggy-backing the notifications on request-style messages (possibily using "batch" requests -- see next question). Similarly some libraries implement server-to-client notifications over HTTP transport by piggy-backing the notifications on response-style messages (possibly using "batch" responses).

Still other libaries make use of HTTP by using WebSockets as their transport protocol. As this does allow bi-directional (essentially) asynchronous communications, then these libaries can properly implement "notification" messages.

If you don't need this you'll have significantly more choice in your selection of transport protocols (and therefore implementations).

Will you need to handle batch requests? Will you need to send batch responses?

Sometimes it is desirable to send/handle groups of requests/responses/notifications in a single request/response (so called "batch" messages). The id argument of the JSON-RPC envelope is used to distinguish requests/responses in a batch.

If you don't need this you'll have significantly more choice in your selection of implementations ("batch messages" is the most commonly ommitted feature of JSON-RPC implementations).

How does the PHP implementation behave under a variety of exception / warning conditions?

PHP has many ways of propagating error conditions to the programmer and also has different types of error condition. Does the server-side implementation handle 'thrown' exceptions and PHP-level errors in a consistent manner? Is the error_reporting configuration appropriate (and does the library change it locally) ? Will the library interact poorly with debugging libraries (e.g: xdebug)?

Does the server-side implementation properly isolate JSON-RPC level errors from HTTP level errors? (i.e: does it prevent errors/exceptions inside a request lifecycle from becoming an HTTP-level error like 500: Internal Server Error).

Does the server-side implementation properly interact with your authentication & authorization mesures? (i.e: it might be desirable to promote related errors to 401: Unauthorized and 403: Forbidden HTTP statuses respectively).

Does the server-side implementation 'leak' sensitive information about your implementation or data-sources when delivering errors, either via HTTP or JSON-RPC?

These are pretty important questions to ask of a JSON-RPC webservice that will be used in a security minded setting. It's pretty hard to evaluate this for a given implementation by reading its documentation. You'll likely need to:

• delve into its source code to look at the error handling strategies employed, and
• perform extensive testing to avoid leaks and undesired propagation of error conditions.

How does the PHP implementation advise against or mitigate the PHP array set/list duality?

PHP is a crappy language. There. I said it :-)

One of the common issues JSON-RPC implementors deal with is how to properly map JSON arrays and JSON objects to language-native datastructures. While PHP uses the same data structure for both indexed and associative arrays, most languages do not. That includes JavaScript, whose language features/limitations informed the JSON (and therefore JSON-RPC) specifications.

As in PHP there is no way to distingish an empty indexed array from an empty associative array, and as various naughty things can be done to muddy existing arrays (e.g: set associative key on existing indexed array) various solutions have been proposed to deal with this issue.

One common mitigation is that the JSON-RPC implementation might force the author to cast all intended-associative arrays to (object) before returning them, and then reject at run-time any (implicity or intended) indexed arrays that have non-confirming keys or non-sequential indexes. Some other server-side libraries force authors to annotate their methods such that the intended array semantics are known at 'compile' time; some try to determine typing through automatic introspection(bad bad bad). Still other sever-side libraries leave this to chance.

The mitigations present/missing in the server-side PHP JSON-RPC implementation will probably be quite indicative as to its quality :-)

Will you need to implement SMD?

SMD is a not-very-standardized extension to JSON-RPC "-like" protocols to allow publishing of WSDL-like information about the webservice endpoint and the functions (no classes, although conventions for namespacing can be found out there) it exposes.

Sometimes 'typing' and 'authorization' concerns are layered with the class/function "annotations" used to implement SMD.

This 'standard' is not well supported in either client or server implementations :-)

Will your web-service also need to perform other HTTP-level routing? (e.g: to static resources)

Some server-side implementations make all sorts of assumptions about how soon during the HTTP request cycle they'll be asked to get involved. This can sometimes complicate matters if the JSON-RPC implementation either implements the HTTP server itself, or constrains the content of all received HTTP messages.

You can often work around these issues by proxying known-JSON-RPC requests to a separate web server, or by routing non-JSON-RPC requests to a separate web-server.

If you need to serve JSON-RPC and non-JSON-RPC resources from the same webserver, ask yourself if the server-side JSON-RPC implemenation makes this impossible, or whether it makes you jump through hoops to work around it.