Hi Amila, On Fri, Jul 26, 2013 at 10:42 AM, Amila Suriarachchi <[email protected]> wrote:
> > > > 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 > Yes. Having a role-per-user == granting permissions to the user in the older way. > > >> 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. > No, we are talking about three things here, Role, User, Permissions. Deleting a role would cascade-delete all permissions associated with that role. Deleting a role of an asset will not delete the users. Thanks, Senaka. > > > 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 > > -- * <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
