All,

Does it make sense to summarize these discussions in the deliverable?

Regards,
Nina

Andreas Maunz wrote:
> I also consider token expiration not an issue we should deal with
> currently.
> Also, the timeout of 24hrs may even be raised to e.g. 48hrs. More
> important, it seems, is to incorporate the Logout function into the
> workflow, to invalidate the token after the task has actually finished.
> User tokens may be indeed employed in service-to-service connections,
> when permissions are necessary that the requesting service does not
> have (e.g. retrieving a specific dataset). As mentioned earlier,
> services should generally have user accounts too, akin to any
> service/daemon on a stand-alone computer.
>
> Greetings
> Andreas
>
>
> Luchesar V. ILIEV wrote on 06/17/2010 12:55 PM:
>> I second Nina's opinion on OpenSSO hardly providing any mechanism to
>> implement such token "half-life". On the other hand, we have the
>> following general workflow:
>>
>> 1. User acquires token via client application.
>> 2. Client application uses token with various services.
>> 3. The services use token on behalf of user when necessary.
>> 4. On getting the final results, the client "logouts" the token.
>>
>> Thus, for each user-initiated "computational flow" through the OpenTox
>> services, a "freshly-issued" token will be used. Considering that
>> currently the tokens have 24 hours validity, I find it rather unlikely
>> to have many cases of tokens expiring "in transit". That's why I'd
>> rather consider the token expiration a non-issue, at least for the
>> time being.
>>
>> Of course, it would be somewhat different with people communicating
>> directly through the API with the OT services. Obviously, they will
>> handle the authentication themselves, and thus it's upon them to keep
>> an eye on token validity. Still, if they are proficient enough to use
>> directly the API, that shouldn't be a problem.
>>
>> Further, we could prepare some "best practices" document, which could
>> give suggestions on how to specifically avoid these issues, e.g.
>> always use "fresh tokens", or "don't use tokens that have less than N
>> hours validity, etc. Actually, the "best practices" might be handy for
>> many other things as well: e.g. what is considered "polite" use of the
>> OT infrastructure, that is what needs to be avoided in order not to
>> overload it...
>>
>> Cheers,
>> Luchesar
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development