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.

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
>