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
