I am also currently working on an entry "Creating a Model" for the 
extended use case example.
@Luchesar: we will have to merge our contributions.

Andreas

Nina Jeliazkova wrote on 06/17/2010 01:20 PM:
> 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
>

-- 
http://www.maunz.de

            All right, who's been cooking hot dogs in the Warp Drive?