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.

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