[xmlrpcflash-development] Re: [xmlrpcflash - Open Discussion] secure functionality with Flash xmlrpc

[Isaac L. <is...@st...>]

Hello there,

My name is Isaac and I'm a new Admin on this project-

On Monday, November 25, 2002, at 04:25 PM, no...@so... 
wrote:

> Dear all,
>
> we are developing the server side of an xmlrpc based application.

Ah, with what?  (In the future, we'd love any write-ups on using xmlrpc 
and flash with different servers...)

> Our partners are developing the client side in Flash, using the 
> xml-rpc library.
> We are keen to use standard HTTP auth mechanisms and SSL, but they are 
> having
> great trouble with this.

I understand this issue.  There are a couple of methods, but they are 
processes outside of the direct scope of xmlrpc:

First, encryption:

1) use https for flash's server communications, but this only works 
when the SWF is played in a web browser.

2) A hash can be made in Flash, (you mention MD5 later), but as hashes 
are a medium/lightweight encryption method- but they would do for good 
protection for general obfuscation.

3) For industrial-duity use, Run the xmlrpc connection through an SSL 
tunnel, (independent of both Flash and the server), though this would 
not be a desired method for heavy-use apps, as SSL can be process 
consuming, and managing keys/certs can be inappropriate for some 
applications)
Good starting points on this would be:
http://www.oreillynet.com/cs/weblog/view/wlg/499
http://www.tacc.utexas.edu/resources/user_guides/ftp/

Second, Secure Auth:

4) HTTP basic authentication (header based) is not covered by the 
xmlrpc spec itself, and any implimentation of it is outside of the 
scope of xmlrpc.  I've been told several xmlrpc implimentations DO 
support user/password auth using this method, but I don't know 
specifically which ones.
Additionally, I have no info on how well Flash would be able to 
consistently perform http auth, as I have found it to have 
bugs/problems with inserting anything in the http header itself, (flash 
4 all the way up to MX),
One such problem is outlined here:
http://www.zope.org/Members/ike/Flash-Zope/FLASH_xmlrpc_zope/

5) If you do successfully augment the HTTP headers from flash, then be 
sure to use the 'X-' prefix, as defined in RFC 1521 
(http://www.ietf.org/frc/rfc1521.txt) to indicate their nonofficial 
nature- (not only for posterity, but trust me- annoying problems can 
arise as the messages fly across the net, if you leave off the X)

6) RECOMMENDED: Encrypt the entire transfer somehow, (using 
SWFhttps->browser->server) and devise some mechanism for password 
authentication between your flash client, and server applications.  
This has been a successful strategy for Zope xmlrpc users; one way has 
been to use:
http://www.zope.org/Members/natesain/RPCAuth


> Having looked over the documentation and source code myself, I can't 
> see any
> support for Auth methods (e.g. setBasicCredentials) in the xmlrpc lib, 
> or the
> underlying XML object (which is used for transport, via the 
> sendAndLoad method).

Right.  As we are in the process of reviving an 18 moonth old Alpha 
software, could you possibly give us any pointers as to how you'd like 
to see them implimented?

I have been discussing that an alternate 'switch' for making the xmlrpc 
object simply switch from http to https would be nice, (assuming 
browser usage), as well as simple to impliment.

Authentication methods, however, would be futile- as they manifest in 
so many varied ways, it would be far outside of the scope of xmlrpc to 
include them- but can be a part of the flash application, and wrapped 
in an xmlrpc post.

> I also noted in some more general Flash security documentation, that 
> XMLSockets
> do not support SSL,  and that the suggested fix is to roll your own MD5
> encryption.

Totally great- any info/URLs you have on this, I'd very much appreciate 
looking at!

>
> Two questions:
>
> 1) Is there any way to use HTTP Auth with Flash xmlrpc?

I hope that I have covered this well enough above,

>
> 2) Are SSL connections supported with Flash xmlrpc, or (I guess if it 
> used XMLSockets
> directly or indirectly) will we need to plug in our own MD5.

XMLSockets and xmlrpc are 2 very different things.  XMLSockets are for 
creating perisistent connections to an appropriate xml socket server, 
whereas xmlrpc is for Post operations.  XMLSocket servers can push data 
to a flash client, whereas xmlrpc, in general applied use, cannot 
(although the xmlrpc spec is so good, and so simple, it has been used 
as the basis for some persistent connections).
XMLSocket servers, based on their continious connection model, are 
incredibly bandwidth consuming- but are a logical choice for Chat/Game 
multi-user applications.

The manner in which these applications use xml data is fundamentally 
different from an xmlrpc communication, (smaller nests of xml data, 
passed back and forth in chunks)- although the data type requirements 
are functionally the same.

If you are interested in XMLSocket servers, Fortress makes a very well 
respected server (uses Java),
http://xadra.com/
and for an Open-Source flash socket server,
http://swocket.sourceforge.net



--
PLEASE NOTE:
If you end up using the xmlrpcflash actionscript library, please be 
aware of the following:

We are currently tearing apart all of the response handling methods, as 
well as re-evaluating the base object handlers- with the aim of having 
a much simpler library for practical use.  Additionally, the Liscense 
is moving from GPL to LGPL, so it's use has little restriction for 
commercial uses.

Keep an ear out for further developments, and if you or your associates 
have time to contribute to the project, (even just critique, 
commentary, feature list...), please join the developers mailing list!

http://lists.sourceforge.net/lists/listinfo/xmlrpcflash-development

Best,
Isaac



   Isaac Levy
+ Office of Structured Systems
   http://structuredsystems.net