As promised, here's the updated deliverable. Feel free to
accept/reject the different changes I've made. There's one thing that
I considered adding, but finally decided that you would likely do it
better: the call to OpenSSO for user's attributes via their token.

Cheers,
Luchesar

P.S. To be honest, there's a lot more to be done on this deliverable,
but of course it will be a matter of balance between quality and time.
And I tried to emphasize in both the summary and conclusions that this
is only an initial implementation -- more of a survey of the problem
and testing the waters rather than a fully blown solution ready for
production.


On Thu, Jun 17, 2010 at 15:22, Andreas Maunz <andreas at maunz.de> wrote:
> Ok, fine. Just send it when you are finished, please.
> Cheers
> Andreas
>
> Luchesar V. ILIEV wrote on 06/17/2010 02:12 PM:
>>
>> 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
>>>
>>
>
> --
> http://www.maunz.de
>
> Let's face the obvious. Yesterday we were nerds. Today we're the cognitive
> elite.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Draft_OpenTox_Deliverable_Report_WP3-D3.3-LI-2.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 371594 bytes
Desc: not available
URL: <http://lists.opentox.org/pipermail/development/attachments/20100618/93ed3eb4/attachment.docx>