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.

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

-- 
Dipl.-Bioinf. Tobias Girschick

Technische Universität München
Institut für Informatik
Lehrstuhl I12 - Bioinformatik
Bolzmannstr. 3
85748 Garching b. München, Germany

Room: MI 01.09.042
Phone: +49 (89) 289-18002
Email: tobias.girschick at in.tum.de
Web: http://wwwkramer.in.tum.de/girschick