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 ?

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

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.

Cheers
Surajit




On Tue, Mar 23, 2010 at 7:48 PM, Luchesar V. ILIEV <luchesar.iliev at gmail.com
> wrote:

> To be honest, I'm a bit worried about the power of these tokens. Sure,
> this gives them great flexibility and makes using them really easy.
> But consider this: each service that is presented with such token (in
> order to authorise the specific action requested) will, essentially,
> have (read-only) access to all the user's data/attributes, _including_
> their password.
>
> Yes, it's just the hash of the password, but this already creates a
> possibility for at least a brute-force attack on it, not to mention
> the inherent flaws in some implementations -- even the venerable SHA1
> algorithm is considered unsafe today, and MD5 (which is still used
> surprisingly widely) could only bring a smile on the face of a
> determined and well-equipped hacker.
>
> For this reason, I'd like to stress once more how very important it is
> to keep the user tokens safe from prying eyes -- or from being
> unintentionally leaked. This holds true not just for the network
> transit, where SSL/TLS will obviously be a must, but also for the
> services themselves in how the handle the tokens.
>
> Cheers,
> Luchesar
>
>
> On Tue, Mar 23, 2010 at 16:03, Nina Jeliazkova <nina at acad.bg> wrote:
> >
> >
> > Andreas Maunz wrote:
> >> Hi Pantelis,
> >>
> >> yes, it is possible.
> >>
> >> Here you can find a condensed list of OpenSSO Services as of 10/2009:
> >> http://blogs.sun.com/docteger/entry/opensso_and_rest
> >> (also given in the document I sent around).
> >>
> >> And this is the specific link to "Display Identity Data":
> >> http://blogs.sun.com/docteger/entry/opensso_and_rest#attributes
> >>
> >> Best regards
> >> Andreas
> >>
> >
> > Just my two cents:
> >
> > There should be additional information as well (not only user names, but
> > the domain  - e.g. the OpenSSO service URI).
> >
> > Regards,
> > Nina
> >> chung wrote on 03/23/2010 02:44 PM:
> >>
> >>> Hi Andreas,
> >>>    There is something that is not yet very clear to me and I think it
> >>> would be of interest for other developers as well. A user logs in and
> >>> gets a token which uses to be identified by the various services in
> >>> OpenTox. Suppose that a user provides its token to a model creation
> >>> service. The created model should have a reference to the user that
> >>> created it (something like ot:createdBy={userName}) which means that
> >>> services need to know the username behind the token . Will it be
> >>> possible to retrieve the username corresponding to a given token?
> >>>
> >>> Best regards,
> >>> Pantelis
> >>>
> >>> On Fri, 2010-03-19 at 14:43 +0100, Andreas Maunz wrote:
> >>>
> >>>> Dear All,
> >>>>
> >>>> please find attached an updated version of the authentication and
> >>>> authorization approach based on OpenSSO.
> >>>>
> >>>> Micha is currently working on migrating OpenTox website users and
> groups
> >>>> into a standalone OpenDS server (LDAP), which is intended to serve as
> >>>> the common backend for both Plone and OpenSSO. This way, we can
> >>>> hopefully use all existing PLONE group configurations for access
> >>>> policies in OpenSSO live!
> >>>>
> >>>> Things look quite promising up to now. A drawback is currently the
> lack
> >>>> of a REST interface for mamnaging policies. Here is an overview over
> the
> >>>> REST interface implemented in OpenSSO as of 10/2009:
> >>>> http://blogs.sun.com/docteger/entry/opensso_and_rest
> >>>>
> >>>> Best regards
> >>>> Andreas
> >>>> _______________________________________________
> >>>> Development mailing list
> >>>> Development at opentox.org
> >>>> http://www.opentox.org/mailman/listinfo/development
> >>>>
> >>>
> >>
> >>
> >
> > _______________________________________________
> > Development mailing list
> > Development at opentox.org
> > http://www.opentox.org/mailman/listinfo/development
> >
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>



-- 
Surajit Ray
Partner
www.rareindianart.com