On Fri, Jul 26, 2013 at 10:51 AM, Senaka Fernando <[email protected]> wrote:
> 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. > if you go ahead with the role approach I think another question you need to think whether to create an internal role or in a user store. And how to use users in newly added stores etc ... thanks, Amila. > > 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 > > -- *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
