On Fri, Oct 7, 2011 at 12:45 PM, Waruna Ranasinghe <war...@wso2.com> wrote:
>
>
> On Fri, Oct 7, 2011 at 12:39 PM, Nuwan Bandara <nu...@wso2.com> wrote:
>
>> Hi
>>
>> On Fri, Oct 7, 2011 at 12:13 PM, Tharindu Mathew <thari...@wso2.com>wrote:
>>
>>>
>>>
>>> On Fri, Oct 7, 2011 at 11:36 AM, Thilina Buddhika <thili...@wso2.com>wrote:
>>>
>>>>
>>>>
>>>> On Fri, Oct 7, 2011 at 11:09 AM, Tharindu Mathew <thari...@wso2.com>wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Oct 7, 2011 at 9:53 AM, Thilina Buddhika <thili...@wso2.com>wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 7, 2011 at 1:18 AM, Tharindu Mathew <thari...@wso2.com>wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 7, 2011 at 1:07 AM, Nuwan Bandara <nu...@wso2.com>wrote:
>>>>>>>
>>>>>>>> Hi Tharindu,
>>>>>>>>
>>>>>>>> If I have explicitly given User-Y read permission for the User-X s
>>>>>>>> resources then its for certain extent fine, but In this case user-Y
>>>>>>>> only
>>>>>>>> have login permission.
>>>>>>>>
>>>>>>>> but anyway if I do a getConfigUserRegistry() I am expecting a
>>>>>>>> registry space which is only accessible for that particular user, else
>>>>>>>> whats
>>>>>>>> the point ?
>>>>>>>>
>>>>>>>> Answer below.
>>>>>>>
>>>>>>>> Regards,
>>>>>>>> /Nuwan
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Oct 7, 2011 at 1:01 AM, Thilina Buddhika <thili...@wso2.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Then why are we taking an additional parameter "username" to the
>>>>>>>>> method getConfigUserRegistry(String userName, int tenantId) ?
>>>>>>>>>
>>>>>>>>> Also what is the difference of the registry instances returned from
>>>>>>>>> getConfigSystemRegistry(int tenantId) and getConfigUserRegistry(String
>>>>>>>>> userName, int tenantId) ?
>>>>>>>>>
>>>>>>>> system registry is for system tasks. It has high privileges, just
>>>>>>> like an admin user or more, which is needed for system tasks.
>>>>>>>
>>>>>>> user registry, is for that user's tasks. So, if you get user X's
>>>>>>> registry, you get the registry with that user's privileges. If he cannot
>>>>>>> read resource /abc/foo, then you can't get and read that resource, with
>>>>>>> user
>>>>>>> X's registry.
>>>>>>>
>>>>>>> You are confusing tenant spaces with user spaces. When you pass the
>>>>>>> tenant id, you get that tenant's registry, which is isolated from other
>>>>>>> tenants. Tenant spaces and user registry are orthogonal concepts.
>>>>>>>
>>>>>>
>>>>>> So this means if we store something in the user registry, it is
>>>>>> secured only by the RBAC model. There is no isolation for each user's
>>>>>> data,
>>>>>> if they do belong to the same role.
>>>>>>
>>>>> Yes. I thought this was obvious :)
>>>>>
>>>>
>>>> Well, it is not obvious if you look at the method name. For me,
>>>> getConfigUserRegistry(int tenantId, String username) gives the notion of I
>>>> am getting a my registry space inside my tenant space.
>>>>
>>> No, it's still a registry. So it is understood that it is shared. What is
>>> the point of having registry that is not shared among users?
>>>
>>
>> So you mean by definition a registry space is always shared ?
>>
>>
>>>
>>>>
>>>>>
>>>>> If you think about this way. What is the point of having user
>>>>> isolation? Registry is there to manage artifacts. So artifacts uploaded by
>>>>> one party, can be and should be manipulated by other users.
>>>>>
>>>>
>>>> Only if they want these resources to be accessed. This statement is
>>>> correct, only if you take a look from the G-Reg's angle. But in Carbon, we
>>>> are using registry for storing almost everything.
>>>>
>>> You should not use the registry to store everything. Only config data.
>>> The current mechanism gives you leverage to define a way that is applicable
>>> to you.
>>>
>>
>> AFAIU, our current programming model in carbon components is that we use
>> the registry as the storage engine.
>>
> Not all the time, BAM and BPS uses it's own db to store data
>
yeah, IFAIK, they are very special cases right ? long running processes and
huge amounts of data ?.
>
> Thanks,
> Waruna
>
>
>> We dont use any other places except the registry to store all the data
>> created by users/artifacts etc.
>>
>> So the current mechanisms makes us create a role per every user if we need
>> user level isolation, which is not really scalable.
>>
>>
>>>
>>>>
>>>>>
>>>>> Only tenant isolation makes sense. Of course, marrying RBAC and CArbon
>>>>> permissions may make sense for some use cases. But, not all the time. I
>>>>> believe this way give the maximum flexibility.
>>>>>
>>>>
>>>> Having tenant isolation does not work always. For example, take the
>>>> usecase Nuwan tries to achieve. That is to maintain individual user's data
>>>> in the registry separately without allowing each of them to mess with
>>>> others' data. With this model, it is not possible to do it without creating
>>>> roles per each user which is not scalable in the case of GS.
>>>>
>>>> Since we are trying to focus more on social aspect of our platform,
>>>> ability to have user level data isolation makes sense.
>>>>
>>>
>>> User level data isolation can be achieved using RBAC, if that is what you
>>> want.
>>>
>>> I govern my artifacts so others can access it. I put my artifacts to a
>>> location where devs can access it during dev stage.
>>>
>>> Nuwan, you can make use of other mechanisms, something like defining
>>> uuids and associating them with a user and making a collection by that name
>>> and storing the data. You are using the registry wrong if you don't want
>>> others having access to a user's data. It makes perfect sense for an admin
>>> to decide which gadgets a user can see. So he can meddle with a user's
>>> gadgets.
>>>
>>
>> IMO, to me that sounds like a hack, we are simply trying to find
>> alternative ways because the registry doesn't support a certain requirement.
>>
>> Regards,
>> /Nuwan
>>
>>
>>>
>>>
>>>> Thanks,
>>>> Thilina
>>>>
>>>>
>>>>>
>>>>>> Thanks,
>>>>>> Thilina
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Thilina
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Oct 7, 2011 at 12:54 AM, Tharindu Mathew <
>>>>>>>>> thari...@wso2.com> wrote:
>>>>>>>>>
>>>>>>>>>> For Nuwan's question, the simple answer is no.
>>>>>>>>>>
>>>>>>>>>> If you have read permissions for that user Y of user X's resource,
>>>>>>>>>> user Y can view it.
>>>>>>>>>>
>>>>>>>>>> Separate registry spaces are only present per tenant.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Oct 7, 2011 at 12:40 AM, Thilina Buddhika <
>>>>>>>>>> thili...@wso2.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Actually we had used governance user registry in permission
>>>>>>>>>>> update task, not config user registry.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Thilina
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Oct 7, 2011 at 12:11 AM, Thilina Buddhika <
>>>>>>>>>>> thili...@wso2.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Nuwan,
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Oct 6, 2011 at 11:48 PM, Nuwan Bandara
>>>>>>>>>>>> <nu...@wso2.com>wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am aware that we have a separate isolated registry space for
>>>>>>>>>>>>> each tenant. However do we have the same for a user.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Yes.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> if I want to take a user's registry and put a value, can
>>>>>>>>>>>>> another user with registry browse permission can see that value.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ie.
>>>>>>>>>>>>>
>>>>>>>>>>>>> User-X and User-Y are in the same tenant = 1
>>>>>>>>>>>>>
>>>>>>>>>>>>> login as user-X
>>>>>>>>>>>>>
>>>>>>>>>>>>> registry = getConfigUserRegistry(1);
>>>>>>>>>>>>> registry.put("repository/foo", bar);
>>>>>>>>>>>>>
>>>>>>>>>>>>> and login as user-Y
>>>>>>>>>>>>>
>>>>>>>>>>>>> registry = getConfigUserRegistry(1);
>>>>>>>>>>>>> registry.get("repository/foo")
>>>>>>>>>>>>>
>>>>>>>>>>>>> will the result be "bar" ?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You will not be allowed to access this resource. I am sure that
>>>>>>>>>>>> this permission model is working fine, because there was an issue
>>>>>>>>>>>> in the
>>>>>>>>>>>> permission update task where it had written a flag to the user
>>>>>>>>>>>> space rather
>>>>>>>>>>>> than the system space.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Thilina
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> *Thanks & Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nuwan Bandara
>>>>>>>>>>>>> Senior Software Engineer
>>>>>>>>>>>>> WSO2 Inc. | http://wso2.com
>>>>>>>>>>>>> lean . enterprise . middleware
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://nuwan.bandara.co
>>>>>>>>>>>>> *
>>>>>>>>>>>>> <http://www.nuwanbando.com/>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Carbon-dev mailing list
>>>>>>>>>>>>> Carbon-dev@wso2.org
>>>>>>>>>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Thilina Buddhika
>>>>>>>>>>>> Associate Technical Lead
>>>>>>>>>>>>
>>>>>>>>>>>> WSO2 Inc. ; http://wso2.com
>>>>>>>>>>>> lean . enterprise . middleware
>>>>>>>>>>>>
>>>>>>>>>>>> phone : +94 77 44 88 727
>>>>>>>>>>>> blog : http://blog.thilinamb.com
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Thilina Buddhika
>>>>>>>>>>> Associate Technical Lead
>>>>>>>>>>> WSO2 Inc. ; http://wso2.com
>>>>>>>>>>> lean . enterprise . middleware
>>>>>>>>>>>
>>>>>>>>>>> phone : +94 77 44 88 727
>>>>>>>>>>> blog : http://blog.thilinamb.com
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Carbon-dev mailing list
>>>>>>>>>>> Carbon-dev@wso2.org
>>>>>>>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Tharindu
>>>>>>>>>>
>>>>>>>>>> blog: http://mackiemathew.com/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Carbon-dev mailing list
>>>>>>>>>> Carbon-dev@wso2.org
>>>>>>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Thilina Buddhika
>>>>>>>>> Associate Technical Lead
>>>>>>>>> WSO2 Inc. ; http://wso2.com
>>>>>>>>> lean . enterprise . middleware
>>>>>>>>>
>>>>>>>>> phone : +94 77 44 88 727
>>>>>>>>> blog : http://blog.thilinamb.com
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Carbon-dev mailing list
>>>>>>>>> Carbon-dev@wso2.org
>>>>>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> *Thanks & Regards,
>>>>>>>>
>>>>>>>> Nuwan Bandara
>>>>>>>> Senior Software Engineer
>>>>>>>> WSO2 Inc. | http://wso2.com
>>>>>>>> lean . enterprise . middleware
>>>>>>>>
>>>>>>>> http://nuwan.bandara.co
>>>>>>>> *
>>>>>>>> <http://www.nuwanbando.com/>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Carbon-dev mailing list
>>>>>>>> Carbon-dev@wso2.org
>>>>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>>
>>>>>>> Tharindu
>>>>>>>
>>>>>>> blog: http://mackiemathew.com/
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Carbon-dev mailing list
>>>>>>> Carbon-dev@wso2.org
>>>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thilina Buddhika
>>>>>> Associate Technical Lead
>>>>>> WSO2 Inc. ; http://wso2.com
>>>>>> lean . enterprise . middleware
>>>>>>
>>>>>> phone : +94 77 44 88 727
>>>>>> blog : http://blog.thilinamb.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> Carbon-dev mailing list
>>>>>> Carbon-dev@wso2.org
>>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>>
>>>>> Tharindu
>>>>>
>>>>> blog: http://mackiemathew.com/
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Carbon-dev mailing list
>>>>> Carbon-dev@wso2.org
>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Thilina Buddhika
>>>> Associate Technical Lead
>>>> WSO2 Inc. ; http://wso2.com
>>>> lean . enterprise . middleware
>>>>
>>>> phone : +94 77 44 88 727
>>>> blog : http://blog.thilinamb.com
>>>>
>>>> _______________________________________________
>>>> Carbon-dev mailing list
>>>> Carbon-dev@wso2.org
>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>> Tharindu
>>>
>>> blog: http://mackiemathew.com/
>>>
>>>
>>> _______________________________________________
>>> Carbon-dev mailing list
>>> Carbon-dev@wso2.org
>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>>
>>>
>>
>>
>> --
>> *Thanks & Regards,
>>
>> Nuwan Bandara
>> Senior Software Engineer
>> WSO2 Inc. | http://wso2.com
>> lean . enterprise . middleware
>>
>> http://nuwan.bandara.co
>> *
>> <http://www.nuwanbando.com/>
>>
>> _______________________________________________
>> Carbon-dev mailing list
>> Carbon-dev@wso2.org
>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>
>>
>
>
> --
> -------------------------------------------------------------------------
> Waruna Ranasinghe
> Senior Software Engineer, WSO2
>
> Mobile: SL +94 724 318285
> BLOG: http://warunapw.blogspot.com
>
> www.wso2.com - "Lean . Enterprise . Middleware"
>
> _______________________________________________
> Carbon-dev mailing list
> Carbon-dev@wso2.org
> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>
>
--
*Thanks & Regards,
Nuwan Bandara
Senior Software Engineer
WSO2 Inc. | http://wso2.com
lean . enterprise . middleware
http://nuwan.bandara.co
*
<http://www.nuwanbando.com/>
_______________________________________________
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
