On Fri, Oct 7, 2011 at 11:36 AM, Thilina Buddhika <[email protected]> wrote:
> > > On Fri, Oct 7, 2011 at 11:09 AM, Tharindu Mathew <[email protected]>wrote: > >> >> >> On Fri, Oct 7, 2011 at 9:53 AM, Thilina Buddhika <[email protected]>wrote: >> >>> >>> >>> On Fri, Oct 7, 2011 at 1:18 AM, Tharindu Mathew <[email protected]>wrote: >>> >>>> >>>> >>>> On Fri, Oct 7, 2011 at 1:07 AM, Nuwan Bandara <[email protected]> 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 <[email protected]>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? > > >> >> 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. > > >> >> 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. > Thanks, > Thilina > > >> >>> Thanks, >>> Thilina >>> >>> >>> >>>> >>>>>> Thanks, >>>>>> Thilina >>>>>> >>>>>> >>>>>> On Fri, Oct 7, 2011 at 12:54 AM, Tharindu Mathew >>>>>> <[email protected]>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 <[email protected] >>>>>>> > 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 < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Nuwan, >>>>>>>>> >>>>>>>>> On Thu, Oct 6, 2011 at 11:48 PM, Nuwan Bandara <[email protected]>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 >>>>>>>>>> [email protected] >>>>>>>>>> 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 >>>>>>>> [email protected] >>>>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> >>>>>>> Tharindu >>>>>>> >>>>>>> blog: http://mackiemathew.com/ >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Carbon-dev mailing list >>>>>>> [email protected] >>>>>>> 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 >>>>>> [email protected] >>>>>> 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 >>>>> [email protected] >>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> >>>> Tharindu >>>> >>>> blog: http://mackiemathew.com/ >>>> >>>> >>>> _______________________________________________ >>>> Carbon-dev mailing list >>>> [email protected] >>>> 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 >>> [email protected] >>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>> >>> >> >> >> -- >> Regards, >> >> Tharindu >> >> blog: http://mackiemathew.com/ >> >> >> _______________________________________________ >> Carbon-dev mailing list >> [email protected] >> 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 > [email protected] > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > -- Regards, Tharindu blog: http://mackiemathew.com/
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
