Luchesar V. ILIEV wrote:
> IMHO, until we have good understanding of what we want in terms of
> accounting, it would be nice to implement only a simple system to
> prevent overloading the services. This could be very simple quota
> system that has hard-coded limit applicable to _any_ user. In fact,
> even that might not be needed for the time being, unless we believe
> that there will be users not careful enough or outright malicious.
>
> Concerning the unique user IDs, what's the problem with Plone's users?
> They are unique identifiers, and the whole AA solutions is centred
> around them at the moment anyway. Even if there are multiple
> OpenSSO's, they'll still use the common LDAP backend pipe to Plone.
>   
Not necessary.  We might decide to setup another OpenSSO server to host
users from  e.g. CADASTER project, who might want to use another backend.

Best regards,
Nina
> Cheers,
> Luchesar
>
>
> On Wed, Jun 16, 2010 at 20:47, Nina Jeliazkova <nina at acad.bg> 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?
>>     
>>> 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
>>>
>>>       
>> _______________________________________________
>> 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
>