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


On Thu, Jun 17, 2010 at 12:58, Nina Jeliazkova <nina at acad.bg> wrote:
> Hi Pantelis,
>
> chung wrote:
>> Hi Nina, All,
>>   Following Nina's scenario, I have the following question: How do we
>> answer the same question for authorization. What if a computational
>> pipeline breaks because of insufficient priviledges, i.e. the services
>> A,B,C are to be invoked one after the other and the user (identified by
>> its token) has access only to the (time consuming) services A and B...?
>>
> Yes , this is indeed a (similar)  issue, Luchesar already had listed it
> in his comments last week.
>
> But the difference is if authorization fails because of an expired
> token, there is at least a theoretical option to renew it, whilst this
> is not possible with hard-wired quotas.
>>    I also have a proposal about token expiration (quick but not dirty).
>> Now the token has two states: Active and Inactive. We can introduce a
>> third state called Stale, where the token will continue to be valid but
>> the end user will be told that this is inactive. Let me explain this. A
>> user acquires a token T1 which it active for t1 hours. The user can use
>> it to perform an action within the next t1/2 hours. After this time the
>> token will expire but only for the end user (services can continue using
>> this token!), so if T1 participates in some computational process it
>> will not really expire. Even if the user posts the token 1sec before its
>> (pseudo)expiration, the token will be valid for the services :-)
>>
> Besides being a security risk, I am not sure OpenSSO could be hacked to
> behave this way.
>
> We've considered another solution, where the services themselves can
> renew the token - using either user credentials, or their own.
>
> Best regards,
> Nina
>> Best regards,
>> Pantelis
>>
>> On Thu, 2010-06-17 at 10:04 +0300, Nina Jeliazkova wrote:
>>
>>> Tobias Girschick wrote:
>>>
>>>> On Wed, 2010-06-16 at 20:47 +0300, Nina Jeliazkova wrote:
>>>>
>>>>
>>>>> chung wrote:
>>>>>
>>>>>
>>>>>> I don't know if there is some more uniform way of doing so, but a
>>>>>> quick-and-dirty solution to the user quota problem is to let the
>>>>>> services decide if the user has exceeded its quota. So when the user
>>>>>> provides a token id to the service shall:
>>>>>>
>>>>>> 1. Ask the SSO server if the token is valid and
>>>>>> 2. If the user is authorized to perform the action and
>>>>>> 3. Retrieve the 'id' of the user. Then count the total number of the
>>>>>> resources generated (on this server) by this user and decide if the user
>>>>>> is allowed to generate one more resource.
>>>>>>
>>>>>>
>>>>>>
>>>>> Who decides on the threshold, and how / if the user can request to
>>>>> modify it?
>>>>>
>>>>>
>>>> I would say the people/person maintaining the server the respective
>>>> service is hosted on. Only those people can judge hard drive space
>>>> limitations of their service. In case of a quota for max. parallel jobs
>>>> per user (something we were discussing some time ago, I think) also the
>>>> maintainers of the server can judge best what the machine can manage and
>>>> what not.
>>>>
>>>>
>>>>
>>> OK, my question is related to the following scenario :
>>>
>>> There is a chained processing (descriptors, models, dataset creation)
>>> and the processing fails in the middle of the chain, because of quota
>>> restrictions as above.
>>>
>>> How one would resolve the issue, in order to succeed when retrying the
>>> calculations?
>>>
>>> Regards,
>>> Nina
>>>
>>>>>> What I mean by user 'id' is some UUID generated to uniquely identify a
>>>>>> user since the name of the user might change, so this 'id' will be
>>>>>> something more "static" (Of course the user will not have to know this
>>>>>> id).
>>>>>>
>>>>>>
>>>>>>
>>>>> user id + identifier of an OpenSSO server might be safer.  ( one can
>>>>> easily have setup with more than one OpenSSO server for various reasons)
>>>>>
>>>>>
>>>>>> I think we could go with this workaround. Any opinions on that?
>>>>>>
>>>>>>
>>>>>>
>>>>> As you said, quick-and-dirty solution :)
>>>>>
>>>>>
>>>> I am not sure if it is that dirty, as it somehow adheres to the very
>>>> distributed character of OpenTox. But still...it's not very
>>>> sophisticated.
>>>>
>>>> Regards,
>>>> Tobias
>>>>
>>>>
>>>>
>>>>> Regards,
>>>>> Nina
>>>>>
>>>>>
>>>>>> Best regards,
>>>>>> Pantelis
>>>>>>
>>>>>>
>>>>>> On Wed, 2010-06-16 at 19:31 +0300, Luchesar V. ILIEV wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I'd say that finding ready-made suitable accounting solution for
>>>>>>> OpenTox is almost impossible. We have seen that even just AA presents
>>>>>>> significant challenge because of the specifics of our data that need
>>>>>>> to be protected. So, if we really want to have quotas implemented,
>>>>>>> that almost certainly means we need to develop the system to handle
>>>>>>> them.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Luchesar
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jun 15, 2010 at 14:31, Andreas Maunz <andreas at maunz.de> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Nina Jeliazkova wrote on 06/15/2010 01:19 PM:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> 3. Every user should be allowed to make use of a pre-specified fraction
>>>>>>>>>>>> of the server's storage capacity which simply means that there should
>>>>>>>>>>>> be
>>>>>>>>>>>> an upper bound on the number of models a user can create (say 50000 or
>>>>>>>>>>>> something like that). How can such a constraint be established using
>>>>>>>>>>>> policies?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Quota support is something we had not yet discussed, but it is indeed
>>>>>>>>>>> important.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Is there some perspective of accomplishing this kind of authorization
>>>>>>>>>> using SSO or web services should take that on?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> This is actually accounting, not authorisation, and we hadn't considered
>>>>>>>>> it at all.   I am slightly in favour of separating accounting from
>>>>>>>>> services.
>>>>>>>>>
>>>>>>>>> Andreas, what do you think?  Does OpenSSO provide a solution for AAA ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> No, I don't think it does. OpenSSO is originally designed to have a single
>>>>>>>> administrator for managing policies and not for different users creating
>>>>>>>> their individual policy (although this is in the pipeline of development at
>>>>>>>> the moment). Therefore, the aspect of controlling the number of policies has
>>>>>>>> been neglected.
>>>>>>>> Other aspects of accounting (e.g. failed attempts to authenticate) are
>>>>>>>> explicitly covered by a special logging service, but I don't think quota is.
>>>>>>>>
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> 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
>