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?
> 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 :)

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
>