On Fri, Oct 7, 2011 at 3:06 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.
>
>
>>
>> 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.
>
>
>>
>> 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.
>
Not only for GS it is not scalable for SQS and other modules which requires
user level permissions.
Let me put my thought on this. There are two ways of authorization.
1. Role based
2. User based.
The role based authorization is more suitable for giving authorizations for
some functionality. For an example we develop Admin console to be used by
some set of user we don't know. So at development time we assign permission
for a role and when the system is deployed in the real environment real user
get imported to the system and they get assigned the roles. Event if we look
at the commonly used software engineering processes we analyze the system
with roles and assign permissions to the roles. (Even real users are not
know at that time). Finally at the deployment time real users get imported
and assign to the roles.
But when the system is being used, real users come and create the resources
for them. Good example is SQS queues. I think same apply for registry
resources as well. Now these resources should belong to the user who created
it. (hence concept of owner ship). Then they can share it with other real
users. Instead of one user it can be done with a user group. (We may use a
role as a user group but I feel it is more related to a set of permissions).
Therefore any authorization manager should have both these features so that
the other developers should be able to use it appropriately.
thanks,
Amila.
>
> Since we are trying to focus more on social aspect of our platform, ability
> to have user level data isolation makes sense.
>
> 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
>
>
_______________________________________________
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
