Hi Surajit,

surajit ray wrote on 03/23/2010 04:30 PM:
> Hi Andreas,
>
> In the scenario that a user action (authenticated by OpenSSO using token) is
> carried out by a web server within the OpenTox framework ... would the web
> server accessing a secondary server, within OpenTox, use the same user token
> OR have a separate authentication token/mechanism for conversations between
> these servers (registered within the OpenTox framework ) ?
>
> The issue is with asynchronous tasks - once a task is started it will go
> through a series of steps involving other servers. For such a task if we are
> using the user token for backend authentication - the task may fail ...
> since the token will be invalidated after a time perdiod (I sure hope it
> does !). In that scenario isn't it better to have a separate authentication
> for server chat ?

The token will be invalidated indeed (this is configurable).
You are raising an important question, and we will have to decide in a 
discussion which route to take.
Also, we will perhaps decide for specific services in a different way 
than for others.

> At this juncture - would like to know which is the bigger priority ....
>
> a) protecting semi-opensource/commercial data available through Opentox
> b) protecting the service delivery servers from DOS attacks etc
> c) protecting generated client data from other clients
>
> Honestly I don't mind an airtight security framework -  but given the
> "opensource" nature of this project , a convoluted and cumbersome security
> mechanism will hinder participation to a great extent ...

I agree an overcomplex A&A mechanism will be rather disadvantageous. The 
security level can be best raised iteratively, perhaps. This will also 
facilitate project-internal usage, since A&A is more a burden than a 
feature from a practical point of view.

> Also in the case of a centralized user authentication system, we would have
> to make sure we have a backup plan in case the main AA server fails -
> otherwise all services may have to halted across all OpenTox servers.

Currently, I use a 7-day rotating backup on the server to secure the 
function of the OpenDS user backend as well as the OpenSSO server itself.

Greetings
Andreas

-- 
http://www.maunz.de
OpenPGP key: http://www.maunz.de/andreas@maunz.de_pub.asc

Real programmers don't document. If it was hard to write, it should be 
hard to understand.