On Tue, 2010-03-23 at 16:43 +0100, Andreas Maunz wrote:
> 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.

I think the problem is solved if:
* A service can call another service providing the username of the user
that triggered the operation and services recognize each-other by their
IPs+MAC address+whatever
* Clients outside the OpenTox net of services, acquire a token from the
a/a service which can be used within a certain time period but is needed
only once to perform an operation (Which implies that services do not
reproduce the token but some persistent property of the user)

What do you think?

Regards,
Pantelis

> 
> > 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
>