Hi Hugh, Hugh Acland wrote:
And here is my main reservation about this wonderful Restful world of distributed computing: how do we authenticate and authorize across the web in a way whereby one web-service (in London), which might be happy dealing with the client’s request, then gets to a point in its logic execution where it needs to enlist the help of another web-service (in Tokyo). If the Tokyo web- service (web-service-san?!) is just providing the temperature then there is probably no need to authenticate but if London (web-service-old-chap?!) wants to ask Tokyo to transfer $100,000 to web-service-cowboy (Texas) then the chances are some how the original security credentials must be parsed around like a children’s party game. And children’s party games always end in tears. Someone always spoils it. So is the current authentication/authorization model - or lack of clarity of purpose – hindering mass take-up of this technology? From a management perspective, the old ways of doing things – thin client, massive load on clustered servers running guargantuan enterprise application server stacks and Berlin-wall style firewall behind which sits all the processing logic and firepower – makes life a lot more secure.
The problems you're talking about are not specific to REST. Credential delegation can be a problem, but there are solutions. Some of them, like Kerberos, have been around for a long time. This type of problem is in fact one of the main challenges that Grid-computing is addressing.
Many of this solutions can be supported by Restlet, or soon will be. We've started some work on SPNEGO (relevant for Kerberos delegation). The SSL extension can accept GSI proxy certificates, via the jsslutils library. It could also support Attribute Certificates (RFC 3281) for example (it's not in jsslutils yet, but it definitely could be).
You'll find, however, that even if the technology is there, the main problems are a matter of policies between institution. If your users or services in London, Tokyo and Texas all belong to the same institution, your could deploy something that uses Kerberos and a single KDC, for example. If not, federating multiple administrative domains to trust each others' assertions of credentials can be legally difficult (whatever the technology behind). On a more technical note, getting these institutions to deploy systems that can talk to each other is also a matter of policy (to this extent, REST might help); getting those who deploy the systems to trust the tools that implement their security isn't easy, because the models they implement are not simple, and because there is an inherent tangling with the legal and political side of security. I've left out discussion on educating users about the security of your system, which shouldn't be neglected of course.
Security through firewalls may look more secure, but certain security mechanism are either (a) too tight, thus preventing the users from actually performing whatever task the system is meant to do (that, you're sure, some managers will complain about, quite rightly so in my opinion) or (b) too complex, in which case, some users won't even bother using the system securely. Security is an exercise that consists of finding the right balance.
Best wishes, Bruno.
