...and, in the X.500 directory context, the two users' DNs would be:

CN=someuser, OU=people, DC=opentox, DC=org
CN=someuser, OU=people, DC=cadaster, DC=eu

L.


On Wed, Jun 16, 2010 at 22:40, Luchesar V. ILIEV
<luchesar.iliev at gmail.com> wrote:
> If you're talking about federations, then Plone users are still
> unique. In the context of federations any UID consists of USER and
> REALM/DOMAIN part, which solves the problem with duplicate usernames
> (besides other things). So, all Plone users will in fact be
> someuser at opentox.org, while CADASTER users will be
> someuser at cadaster.eu.
>
> Cheers,
> Luchesar
>
>
> On Wed, Jun 16, 2010 at 22:06, Nina Jeliazkova <nina at acad.bg> wrote:
>> 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
>>>
>>
>> _______________________________________________
>> Development mailing list
>> Development at opentox.org
>> http://www.opentox.org/mailman/listinfo/development
>>
>