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
>>
>>     
>
>