On 11 June 2011 09:49, surajit ray <mr.surajit.ray at gmail.com> wrote:

> I had something more substantial in mind ... since along with such issues
> there are issues of  "clean up" as well.
>
> Keeping the OpenSSO server as is , we could run a small application called
> a
> "delegate" on the service server. The delegate can, through SSH or other
> encrypted means , maintain a connection with the main SSO server. The
> delegate will maintain user credentials mirrored from the main OpenSSO
> server, the only difference being it will do it for only those users that
> are using the services. The delegate would have its own policy which would
> include permissions to create tokens for non-logged in users who had logged
> in and initiated a job in the past.
>
> The delegate will also have the ability to track user interactions and
> usages of the services and send the same data to a centralized server, or
> maintain it locally till it is requested by a service.
>
> Also in case of a perceived security hole from one of the delegates, the
> privileges of the delegate could be revoked which would dissable the token
> generation via the delegate.
>
> This is just a beginning of an idea really, and would like to know what
> others think about solving this problem.
>



I might be wrong, but sounds like reinvention of certificates, web of trust
, certificates revocation and all the stuff security research has been
working for decades (and have some solution).   More experienced in security
in this list ( yes, there are :) could elaborate.

We should not forget OpenSSO was one of the possible (quick) solutions to
secure OpenTox framework, and not necessarily completely fit for this
purpose (for variety of reasons).  But there is a general recommendation,
when introducing security solutions into any system, to follow existing
solutions, for the reason they have already been scrutinized by number of
security experts worldwide for potential holes.

Nina


>
> On 11 June 2011 13:17, Nina Jeliazkova <jeliazkova.nina at gmail.com> wrote:
>
> > On 9 June 2011 09:30, Andreas Maunz <andreas at maunz.de> wrote:
> >
> > > On Thu, 9 Jun 2011 11:34:43 +0700, surajit ray
> > > <mr.surajit.ray at gmail.com> wrote:
> > > > Hi Andreas,
> > > >
> > > > On 9 June 2011 01:41, Nina Jeliazkova <jeliazkova.nina at gmail.com>
> > wrote:
> > > >> On 8 June 2011 13:38, surajit ray <mr.surajit.ray at gmail.com> wrote:
> > > >>
> > > >>> Hi Nina, Andreas,
> > > >>>
> > > >>> In the A&A workflow a token has a certain life time after which it
> > > >>> becomes invalid. So if someone starts a task and provides a token
> for
> > > >>> dataset access and upload - the access will work as it is done
> > > >>> immediately and the token is valid, however the upload will fail as
> > by
> > > >>> that time the token would become invalid (as the task takes a long
> > > >>> time). One way would be store the user credentials on the server
> > > >>> (Maxtox) which I think is not the correct thing to do. The
> > credentials
> > > >>> should exists only in one secure place.
> > > >>>
> > > >>
> > > >> One solution could be to try to renew the token, while it is still
> > > valid.
> > > >>
> > > >
> > > > Whats the mechanism to renew tokens ?
> > >
> > > I am not aware of any such (OpenSSO-internal) mechanism (which does not
> > > mean it doesn't exist, however).
> > >
> >
> > I had in mind simply getting a new token, given a valid one is available.
> > However, if I remember right,  from a valid token one can retrieve the
> user
> > name, but not the password, and therefore will not have credentials to
> > request a new token.
> >
> > Eventually, the service can get a new token with its own credentials (if
> > such exist), and assign the new resource a policy, granting access only
> to
> > the user, initiating the calculation - through the
> > discussed-but-not-implemented-so-far parameter "policy".
> >
> > Regards,
> > Nina
> >
> >
> > > I see no apparent solution to the problem you mentioned besides raising
> > > token lifetime globally.
> > >
> > > 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
> >
>
>
>
> --
> Surajit Ray
> Partner
> www.rareindianart.com
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>