Jean-Baptiste BRIAUD -- Novlog wrote:
> On 24 Nov 2008, at 09:10, Burak Arslan wrote:
>
>
>> Jean-Baptiste BRIAUD -- Novlog wrote:
>>
>>> Hi,
>>>
>>>
>>>
>> hey
>>
>>> I'd like to share some thought, please don't hesitate to give
>>> feedback.
>>>
>>> Thanks to qooxdoo, it is possible to maintain application state(s) on
>>> client side.
>>> So, why bother with HTTP session on backend ?
>>>
>>>
>>>
>> uh...
>>
>>> OK, let's build a stateless backend that manage data transaction but
>>> then, how to ensure security ?
>>>
>>>
>>>
>> yeah, you have to have some form of authentication.
>>
> Sure.
>
>>> 1. server security : how to ensure that only qooxdoo frontend is able
>>> to make call
>>> => no idea there ... maybe some magic number returned by any call and
>>> that should be given back for next call or something like that ?
>>> I'm afraid that would force server to maintain a context and then
>>> HTTP
>>> session that I would like to kill.
>>> Any idea ?
>>>
>>>
>>>
>> this sort of problem is not present only with qooxtoo type of apps. i
>>
> You right.
>
>> don't want to go into detail here, but i've done the research, and
>> what
>> you're asking for is impossible for a javascript app considering the
>>
> It is impossible, I agree, but we can try to make it as hard as possible
>
>> current technology. with a platform-bound regular desktop app, it
>> would
>> be possible. how? [1] has an answer.
>>
> I'll have a look, just in case there are some ideas that could apply
> to qooxdoo client.
>
it won't apply to qooxdoo type of apps, because it requires specific
hardware. (a tpm). google for trusted computing for more info. or
better, watch this: http://www.lafkon.net/tc/
there's no other absolute solution. tpm neither is an absolute solution,
but it raises the bar from "some guy in mom's basement" to "some well
educated team of people who have a deep understanding of cryptanalysis
and reverse engineering techniques employed by goverments". you can't do
a web application that requires specific hardware, it's an oxymoron :)
of course, you can make it as complex as you can. but i personally don't
think it's worth the effort because you still own the data pipes. and
even if you were not, for example, ibm reportedly does zero effort to
secure db2 against crackers because it's plain impossible to do so.
>>> 2. application security : how to ensure only logged users can play
>>> with application
>>> => Maybe the solution could be to pass user/password as two first
>>> parameters on each call, so the server would check the user is
>>> allowed
>>> without maintaining a state of logged users.
>>> This would cause a little performance cost but that could be done in
>>> memory to optimize without needed a server state.
>>>
>>> In fact, one could wonder why I want so hard to kill that HTTP
>>> session
>>> on server side ...
>>> The answer is simple : to scale. When server is stateless,
>>> loadbalancing become obvious.
>>>
>>>
>>>
>> no it doesn't, unless your data is absoutely read only. you still have
>>
> Don't mix HTTP session and data sync, this is 2 differents things.
>
> Consider all the rest as a (interesting) parenthesis, as it is not
> link to the subject : how to secure stateless server.
>
>
> (
> The architecture I have in mind and that I should have described to be
> clear is the following :
> 1 load balancer : the backend entry point for all incomming HTTP
> request.
> * servers that process business logic, SQL access, ...
> 1 database server
>
> Because there is only one database server, you don't have to sync data.
> In case I would have to, I'll rely on database replication to do it.
>
now i see what you have in mind. then you have two options:
1) using a cluster file system (ocfs, gfs, andrew, coda) and share
sessions the way php does.
2) or use a self contained ticket: take your client's session
identifier, encrypt it (using a private key crypto algorithm like aes,
bluefish, 3des, etc) with a key known only by your servers, and sign it
using hmac algorithm (to make it tamper-proof). first thing you do when
you get the request, you verify then decrypt the key to see who's
sending the request. this way, you're sure that you're getting the same
cookie you sent. you can't be sure that you're getting it from the
client that's supposed to get it. you need a both-ways authenticated
ssl/tls for that. (i.e. a client certificate)
you will of course want to include an expiration date in the ticket.
some paranoids also include ip addresses etc. to make it more secure,
but then your cookie starts to get huge (for a cookie).
kerberos V is the ultimate authentication algorithm, you can study it.
it's huge, i warn you.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
