True, other parties (companies, organizations) may bring their own 
OpenSSO instance.
Regardless of the implementation of the backend (OpenLDAP vs. OpenDS vs 
....) users are always represented in a directory as described by Luchesar.
By simply federating OpenSSO instances (Federation is a matter of a few 
clicks in the backend), we attach those other parties to the OpenTox 
network.
Users can then use their original identities in OpenTox.

A.

Luchesar V. ILIEV wrote on 06/16/2010 09:44 PM:
> ...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
>>>
>>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development

-- 
http://www.maunz.de

                To know recursion, you must first know recursion.