It'll be probably best if I send my document (when it's ready) to you.
The changes I've made will again be "tracked".

Cheers,
Luchesar


On Thu, Jun 17, 2010 at 14:47, Andreas Maunz <andreas at maunz.de> wrote:
> 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?
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>