Hi, If we are going for another permission model as said we have to duplicate stuff and more over that needs to co-exist with the existing permission model because current roles in LDAP/AD are being used for granting permissions for resources. ( That mean what we have in the permission table in resource view should co-exist with new permission model) . So by using the internal roles eliminates that requirement as well.
Thanks On Tue, Jul 23, 2013 at 5:14 PM, Senaka Fernando <[email protected]> wrote: > Hi all, > > First of all, I should've mentioned that these roles are internal roles, > meaning that those wouldn't end up appearing on the LDAP/AD. > > Apart from that, Eranda, I don't think that inventing another permission > model would be a good idea, since we'd essentially be duplicating a lot of > functionality that is being provided. Needless to say UM needs to be able > to accommodate roles of such sort in the future with the introduction of > circles etc in the future. So, I'm still not convinced that the proposed > model is going to create any issues. > > Thanks, > Senaka. > > > On Tue, Jul 23, 2013 at 4:40 PM, Eranda Sooriyabandara <[email protected]>wrote: > >> Hi Senaka, >> >> >> >> On Tue, Jul 23, 2013 at 3:03 PM, Senaka Fernando <[email protected]> wrote: >> >>> Hi Eranda, >>> >>> The role per user model did have one major limitation, where if we >>> wanted to compute who owns (or can edit/view) an Asset, we had to scan >>> through all users and figure out who's roles include permissions for a >>> particular asset. OTOH, if the asset did have a permission of its own, >>> its much easier to compute that information. However, for products like >>> UES, a separate need of a role-per-user exists, but according to what we >>> discussed during the Store meeting, this use-case would benefit by having a >>> role-per-asset model. >>> >>> WDYT? >>> >> >> The scalability vise this is not a good solution. Instead why can't we >> have a separate DB table for Resource Ownership. To read a resource and >> write to a resource permissions we can use the default permission model. >> Since this table is independent we are not migrating. >> >> thanks >> Eranda >> >> >> >>> >>> Thanks, >>> Senaka. >>> >>> >>> On Tue, Jul 23, 2013 at 2:40 PM, Eranda Sooriyabandara >>> <[email protected]>wrote: >>> >>>> Hi Senaka, >>>> >>>> >>>> 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. >>>>> +++++++++++++++++++++ >>>>> >>>>> 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? >>>>> >>>> >>>> Do we need to create a role for each asset? Can't we have a role per >>>> user which has the ownership details, which may be more scalable if there >>>> are lots of artifacts. >>>> >>>> >>>>> >>>>> 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. >>>>> >>>> >>>> Can't we have a new tab "My Resources" under Main -> Resources. >>>> >>>> >>>>> >>>>> 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). >>>>> >>>> >>>> We can specify this level of privileges if we have role per user model. >>>> >>>> thanks >>>> Eranda >>>> >>>> >>>>> >>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Eranda Sooriyabandara >>>> *Senior Software Engineer; >>>> Integration Technologies Team; >>>> WSO2 Inc.; http://wso2.com >>>> Lean . Enterprise . Middleware >>>> >>>> E-mail: eranda AT wso2.com >>>> Mobile: +94 716 472 816 >>>> Linked-In: http://www.linkedin.com/in/erandasooriyabandara >>>> Blog: http://emsooriyabandara.blogspot.com/ >>>> >>>> >>>> >>>> * >>>> * >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> *Eranda Sooriyabandara >> *Senior Software Engineer; >> Integration Technologies Team; >> WSO2 Inc.; http://wso2.com >> Lean . Enterprise . Middleware >> >> E-mail: eranda AT wso2.com >> Mobile: +94 716 472 816 >> Linked-In: http://www.linkedin.com/in/erandasooriyabandara >> Blog: http://emsooriyabandara.blogspot.com/ >> >> >> >> * >> * >> >> _______________________________________________ >> 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 > > -- *Shelan Perera* Senior Software Engineer ** Integration Technology Group *WSO2, Inc. : wso2.com* lean.enterprise.middleware. *Blog* : blog.shelan.org *Linked-i*n : http://www.linkedin.com/pub/shelan-perera/a/194/465 *Twitter* : https://twitter.com/#!/shelan *Mobile* : +94 772 604 402
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
