On Fri, Jul 26, 2013 at 10:33 AM, Senaka Fernando <[email protected]> wrote:
> Hi Amila, > > Let me explain how the role-per-asset model works better than the > role-per-user model when deleting an asset. Say you have a Asset X and the > role for it X' and a user of the Asset U and the role for the user U'. > > The relationship between X and X' is 1-to-1 and X and U is 1-to-M. Now, if > you delete an Asset from the system, we need to scan all users to figure > out which users have a permission for X if we use the role-per-user model. > I think you mean user-permission model > But, if you had the role-per-asset model, we just need to remove that role. > What about users assigned to that role? When you delete role you need to delete them too. thanks, Amila. > > Likewise, if we move an asset from one place to another, its just a matter > of updating a single role (X') instead of changing multiple users' roles > (U'). > > The idea behind the role-per-asset model came because assets are what get > added, deleted, moved and copied frequently, but users are not frequently > subject to changes. > > Thanks, > Senaka. > > > On Fri, Jul 26, 2013 at 7:11 AM, Amila Suriarachchi <[email protected]>wrote: > >> >> >> >> On Wed, Jul 24, 2013 at 10:29 AM, Senaka Fernando <[email protected]>wrote: >> >>> Hi Amila, Srinath, >>> >>> Authorize permission does exactly what you meant by this new permission. >>> >> >> Then there is nothing to do :). >> >> >>> However, the issue is we only have role-based permissions and no >>> user-based permissions, which is why we need to create a role and add users >>> to that role in order to grant permissions. We have realized that >>> user-based permissions wont scale, which is why we got rid of that from the >>> kernel. >>> >> >> What is this scalability problem? >> >>> >>> Also, there were other pros related to having a role-per-asset model, >>> which is being able to support situations of people leaving where we can >>> easily add another user to the roles in which the current user was in, but >>> with per user permissions, the management aspect becomes very complicated. >>> >> >> I am thinking in other way :). >> >> If I have a resource and a permission (rp1) and assign this permission to >> u1, now (without directly assign user to permission) I need to create a >> role (r1) (having only that permission) and assigning r1 to permission and >> role to user. >> >> u1 --> r1 --> rp1 >> >> If there is another user I can assign that role to another user. but how >> that make easy than assign that permission to the user. Both cases we do >> one assignment. Here role is a one to one thing with the permission. >> >> What happen if some one delete the resource? in that case we need to >> delete role permission assignment, role, and role user assignments. but in >> above case only user permission assignment. >> >> thanks, >> Amila. >> >> >> >> >> >>> These were all discussed during the WSO2 Store milestone meeting. >>> >>> Thanks, >>> Senaka. >>> >>> On Tue, Jul 23, 2013 at 5:46 PM, Amila Suriarachchi <[email protected]>wrote: >>> >>>> >>>> >>>> >>>> On Tue, Jul 23, 2013 at 2:17 PM, Senaka Fernando <[email protected]>wrote: >>>> >>>>> Hi all, >>>>> >>>>> This is WRT, #1725 on Redmine. >>>>> >>>>> +++++++++++++++++++++ >>>>> The idea is to create a special role that gives READ, WRITE, DELETE >>>>> and AUTHORIZE access to a particular asset making it possible for a >>>>> particular user or set of users take ownership of it. This thought came up >>>>> during a WSO2 Store Milestone Planning Meeting, and mimics the >>>>> functionality of Google Docs. >>>>> +++++++++++++++++++++ >>>>> >>>> >>>> What about defining a new Permission called RWDA (which means if a user >>>> has this permission they can do all tasks) for each assert? Then we can >>>> assign give this permission to who ever user need that. >>>> >>>> thanks, >>>> Amila. >>>> >>>> >>>>> >>>>> Before going ahead with this, we have a few things to get clarified. >>>>> >>>>> 1. How would this role be named? This shouldn't be the name of the >>>>> Asset itself, because there can be multiple assets by the same name. It >>>>> even cant be name + namespace (or similar prefix/postfix), because there >>>>> can be assets that differ by version. So, what's the best way to name it? >>>>> >>>>> 2. How should we be displaying this role in the management console? >>>>> Should it show up just like any other role, or is there some special >>>>> treatment in the Registry Browser? Since the role and the asset are >>>>> 1-to-1, >>>>> we shouldn't be displaying such roles against other assets, which makes it >>>>> require some special treatment. >>>>> >>>>> 3. Is it just one such role or more? For instance, G-Docs has three >>>>> types of privileges when it comes to sharing (i.e. View, Edit, Owner). >>>>> >>>>> Appreciate some quick responses on these in order to make it possible >>>>> for us to ship this with G-Reg 4.6.0, making it available for WSO2 Store >>>>> etc. >>>>> >>>>> Thanks, >>>>> Senaka. >>>>> >>>>> -- >>>>> * <http://us13.wso2con.com/> >>>>> * >>>>> * >>>>> * >>>>> *Senaka Fernando* >>>>> Senior Technical Lead; WSO2 Inc.; http://wso2.com* >>>>> Member; Apache Software Foundation; http://apache.org >>>>> >>>>> E-mail: senaka AT wso2.com >>>>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 >>>>> Linked-In: http://linkedin.com/in/senakafernando >>>>> >>>>> *Lean . Enterprise . Middleware >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Amila Suriarachchi* >>>> >>>> Software Architect >>>> WSO2 Inc. ; http://wso2.com >>>> >>>> lean . enterprise . middleware >>>> >>>> phone : +94 71 3082805 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> * <http://us13.wso2con.com/> >>> * >>> * >>> * >>> *Senaka Fernando* >>> Senior Technical Lead; WSO2 Inc.; http://wso2.com* >>> Member; Apache Software Foundation; http://apache.org >>> >>> E-mail: senaka AT wso2.com >>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 >>> Linked-In: http://linkedin.com/in/senakafernando >>> >>> *Lean . Enterprise . Middleware >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Amila Suriarachchi* >> >> Software Architect >> WSO2 Inc. ; http://wso2.com >> lean . enterprise . middleware >> >> phone : +94 71 3082805 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > * <http://us13.wso2con.com/> > * > * > * > *Senaka Fernando* > Senior Technical Lead; WSO2 Inc.; http://wso2.com* > Member; Apache Software Foundation; http://apache.org > > E-mail: senaka AT wso2.com > **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 > Linked-In: http://linkedin.com/in/senakafernando > > *Lean . Enterprise . Middleware > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Amila Suriarachchi* Software Architect WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 71 3082805
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
