Hi Sanjeewa, On Thu, May 18, 2017 at 5:09 PM, Sanjeewa Malalgoda <[email protected]> wrote:
> I don't think its worth to get complete permission model for comments as > well. Like bhathiya mentioned only comment owner is allowed to > update/delete his comment. That is the normal behavior. Also i feel its > better if we can have work flow support for comments(by default this need > to disabled). Once something posted if we let someone else to modify its > not nice. > Admin or similar role might be needing moderator capability for comments. WDYT? To support that we can easily use existing permission model. Thanks, Bhathiya > > Thanks, > sanjeewa. > > On Thu, May 18, 2017 at 11:20 AM, Fazlan Nazeem <[email protected]> wrote: > >> Hi Nuwan/Bhathiya, >> >> On Tue, May 9, 2017 at 10:19 AM, Nuwan Dias <[email protected]> wrote: >> >>> I think what Bhathiya is suggesting is to bring in our usual permissions >>> model (in APIM 3.0.0) to comments as well. This will require more data to >>> be saved in the DB but will address the issue at hand. >>> >>> >> Are you suggesting we should have an extra column in Comments table in >> the db to fulfill this? >> >> I am thinking of using the AM_API_PERMISSION column introduced in AM_API >> table to decide on who can update/delete a specific comment. Apart from the >> user who commented, If a user can delete or update an API he can >> delete/update any comment for that API. This way we do not need to save >> extra information in the db, and can use the api permission information to >> control the comment actions. >> >> There are two levels of permissions required here. One is "who can >>> add/update/remove comments in general" and the other is "whose comments can >>> I update/remove". >>> >>> The first can be simply achieved using scopes. Basically say which scope >>> is permitted for the /comments API. The second can be solved by using our >>> usual permission model in APIM v3.0.0. >>> >>> On Tue, May 9, 2017 at 10:10 AM, Ayyoob Hamza <[email protected]> wrote: >>> >>>> This won't tackle the problem Musthaq suggested which requires >>>> validation in the backend. >>>> >>>> *Ayyoob Hamza* >>>> *Senior Software Engineer* >>>> WSO2 Inc.; http://wso2.com >>>> email: [email protected] cell: +94 77 1681010 <%2B94%2077%207779495> >>>> >>>> On Tue, May 9, 2017 at 10:01 AM, Ayyoob Hamza <[email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> We had a similar requirement to have a fine grained access for users >>>>> in IoTS and we went with the approach of assigning permission for scope >>>>> rather than roles. >>>>> >>>>> *Ayyoob Hamza* >>>>> *Senior Software Engineer* >>>>> WSO2 Inc.; http://wso2.com >>>>> email: [email protected] cell: +94 77 1681010 <%2B94%2077%207779495> >>>>> >>>>> On Tue, May 9, 2017 at 9:51 AM, Mushthaq Rumy <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Prasanna/Pubudu, >>>>>> >>>>>> I think if we use scope based validation there will be an issue here. >>>>>> Lets take the same example. >>>>>> >>>>>> >>>>>> >>>>>> *GET /apis/{apiId}/comments/{commentId} - >>>>>> comment-add-scopeDELETE /apis/{apiId}/documents/{documentId} - >>>>>> comment-delete-scopeUPDATE /apis/{apiId}/documents/{documentId} - >>>>>> comment-update-scope* >>>>>> >>>>>> Scope and roles matching are as follows. >>>>>> >>>>>> *comment-add-scope : subscriber-role, **admin-role* >>>>>> *comment-**update**-scope : **subscriber-role, **admin-role* >>>>>> *comment-delete-scope : **admin-role* >>>>>> >>>>>> Lets say there are two store users *A* and *B* who have the >>>>>> *subscriber-role. >>>>>> *And user *A* adds a comment to an API (*comment-add-scope*). Then >>>>>> user *B *logs in and he will be able to update that particular >>>>>> comment which user *A *has added since user *B *has the >>>>>> *subscriber-role* too. >>>>>> >>>>>> IMO this should not be allowed. AFAIC we might have to go with user >>>>>> validation. >>>>>> If we can get the logged in user's roles and if that user has >>>>>> admin-role or that particular comment is added by the logged in user we >>>>>> can >>>>>> allow this user to update or delete the comment. WDYT? >>>>>> >>>>>> Thanks & Regards, >>>>>> Mushthaq >>>>>> >>>>>> On Tue, May 9, 2017 at 6:31 AM, Prasanna Dangalla <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Fazlan, >>>>>>> >>>>>>> I think as Ishara and Pubudu have mentioned we can use the scope >>>>>>> validation. >>>>>>> >>>>>>> On Tue, May 9, 2017 at 12:03 AM, Pubudu Gunatilaka <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> + Adding architecture mail group >>>>>>>> >>>>>>>> On Mon, May 8, 2017 at 11:59 PM, Pubudu Gunatilaka < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Fazlan, >>>>>>>>> >>>>>>>>> As Ishara mentioned above, we can do this with scope validation. >>>>>>>>> Each and every resource has a scope. The scope is associated with one >>>>>>>>> or >>>>>>>>> more roles. Consider the following example. >>>>>>>>> >>>>>>>>> Resource and scope matching are as follows. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *GET /apis/{apiId}/comments/{commentId} - >>>>>>>>> comment-add-scopeDELETE /apis/{apiId}/documents/{documentId} - >>>>>>>>> comment-manage-scopeUPDATE /apis/{apiId}/documents/{documentId} >>>>>>>>> - >>>>>>>>> comment-manage-scope* >>>>>>>>> >>>>>>>>> Scope and roles matching are as follows. >>>>>>>>> >>>>>>>>> *comment-add-scope : subscriber-role, **admin-role* >>>>>>>>> *comment-manage-scope : admin-role* >>>>>>>>> >>>>>>>> >>>>>>> @Pubudu: >>>>>>> >>>>>>> IMO a person who adds a comment should have the UPDATE privilege as >>>>>>> well. DELETE can be restricted to admin. Like wise we might find many >>>>>>> combinations with different use cases. So I think its better to decouple >>>>>>> this *comment-manage-scope *to two different scopes as >>>>>>> *comment-update-scope *and *comment-delete-scope. *If we do this, >>>>>>> we can assign it to respective roles in scope and role mapping for >>>>>>> different use cases. >>>>>>> >>>>>>> Thanks >>>>>>> Prasanna >>>>>>> >>>>>>>> >>>>>>>>> When a user hits the GET resource we can do the following. >>>>>>>>> >>>>>>>>> 1. Retrieve the scope of the resource >>>>>>>>> 2. Retrieve the roles of the scope >>>>>>>>> 3. Validate the user based on the role and allow or deny the >>>>>>>>> request. >>>>>>>>> >>>>>>>>> Thank you! >>>>>>>>> >>>>>>>>> On Mon, May 8, 2017 at 5:04 PM, Fazlan Nazeem <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, May 8, 2017 at 3:59 PM, Ishara Cooray <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> How about introducing scope based permission model? >>>>>>>>>>> >>>>>>>>>>> We can define scope for each resource and validate against the >>>>>>>>>>> logged in user scopes. >>>>>>>>>>> This way we can let the admin to edit the scope so that he can >>>>>>>>>>> fine grain the access to these resources. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> My understanding is, with scopes what we can decide is whether a >>>>>>>>>> particular user has access to hit an API resource URL. In my example >>>>>>>>>> all >>>>>>>>>> users with subscriber scope will have access to hit the api, but the >>>>>>>>>> question is, out of those subscribers how do we choose the right >>>>>>>>>> subscriber >>>>>>>>>> for the right action. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks & Regards, >>>>>>>>>>> Ishara Cooray >>>>>>>>>>> Senior Software Engineer >>>>>>>>>>> Mobile : +9477 262 9512 <+94%2077%20262%209512> >>>>>>>>>>> WSO2, Inc. | http://wso2.com/ >>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>> >>>>>>>>>>> On Mon, May 8, 2017 at 3:42 PM, Fazlan Nazeem <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> This is about how we should handle access permission for >>>>>>>>>>>> subresources in api store. >>>>>>>>>>>> >>>>>>>>>>>> *Parent Resource Access * >>>>>>>>>>>> >>>>>>>>>>>> Consider the following REST calls. >>>>>>>>>>>> >>>>>>>>>>>> GET /apis/{apiId}/comments/{commentId} >>>>>>>>>>>> GET apis/{apiId}/documents/{documentId} >>>>>>>>>>>> >>>>>>>>>>>> At the moment we are not checking whether a particular user has >>>>>>>>>>>> read access to the specific api before we retrieve the requested >>>>>>>>>>>> comment or >>>>>>>>>>>> document. Is it fine to ignore this check for these apis assuming >>>>>>>>>>>> that a >>>>>>>>>>>> user might be already having read access to the api because he >>>>>>>>>>>> already >>>>>>>>>>>> knows the uuid of the api? >>>>>>>>>>>> >>>>>>>>>>>> Or should we be doing an explicit permission validation? Do we >>>>>>>>>>>> have any drawbacks in doing this check? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *Subresource Update/Delete* >>>>>>>>>>>> >>>>>>>>>>>> Consider the following REST api calls done by a user in store. >>>>>>>>>>>> >>>>>>>>>>>> DELETE /apis/{apiId}/comments/{commentId} >>>>>>>>>>>> UPDATE /apis/{apiId}/comments/{commentId} >>>>>>>>>>>> >>>>>>>>>>>> DELETE /apis/{apiId}/documents/{documentId} >>>>>>>>>>>> UPDATE /apis/{apiId}/documents/{documentId} >>>>>>>>>>>> >>>>>>>>>>>> In order to restrict who can update and delete these >>>>>>>>>>>> subresources, we can pass the username to DAO layer and check who >>>>>>>>>>>> created >>>>>>>>>>>> it, and allow only that person to do these modifications. But >>>>>>>>>>>> there could >>>>>>>>>>>> be a use-case where another user(admin) will need to delete or >>>>>>>>>>>> update a >>>>>>>>>>>> resource created by someone else. If we restrict only the creator >>>>>>>>>>>> to do >>>>>>>>>>>> these actions, then we cannot support such a use-case. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Appreciate your thoughts on this. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Thanks & Regards, >>>>>>>>>>>> >>>>>>>>>>>> Fazlan Nazeem >>>>>>>>>>>> >>>>>>>>>>>> *Senior Software Engineer* >>>>>>>>>>>> >>>>>>>>>>>> *WSO2 Inc* >>>>>>>>>>>> Mobile : +94772338839 >>>>>>>>>>>> <%2B94%20%280%29%20773%20451194> >>>>>>>>>>>> [email protected] >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Thanks & Regards, >>>>>>>>>> >>>>>>>>>> Fazlan Nazeem >>>>>>>>>> >>>>>>>>>> *Senior Software Engineer* >>>>>>>>>> >>>>>>>>>> *WSO2 Inc* >>>>>>>>>> Mobile : +94772338839 >>>>>>>>>> <%2B94%20%280%29%20773%20451194> >>>>>>>>>> [email protected] >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Pubudu Gunatilaka* >>>>>>>>> Committer and PMC Member - Apache Stratos >>>>>>>>> Software Engineer >>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>> mobile : +94774078049 <%2B94772207163> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Pubudu Gunatilaka* >>>>>>>> Committer and PMC Member - Apache Stratos >>>>>>>> Software Engineer >>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>> mobile : +94774078049 <%2B94772207163> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Mushthaq Rumy >>>>>> *Software Engineer* >>>>>> Mobile : +94 (0) 779 492140 <%2B94%20%280%29%20773%20451194> >>>>>> Email : [email protected] >>>>>> WSO2, Inc.; http://wso2.com/ >>>>>> lean . enterprise . middleware. >>>>>> >>>>>> <http://wso2.com/signature> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Nuwan Dias >>> >>> Software Architect - WSO2, Inc. http://wso2.com >>> email : [email protected] >>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Thanks & Regards, >> >> Fazlan Nazeem >> >> *Senior Software Engineer* >> >> *WSO2 Inc* >> Mobile : +94772338839 >> <%2B94%20%280%29%20773%20451194> >> [email protected] >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 <071%20306%208779> > > <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda. > blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/> > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Bhathiya Jayasekara* *Associate Technical Lead,* *WSO2 inc., http://wso2.com <http://wso2.com>* *Phone: +94715478185* *LinkedIn: http://www.linkedin.com/in/bhathiyaj <http://www.linkedin.com/in/bhathiyaj>* *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* *Blog: http://movingaheadblog.blogspot.com <http://movingaheadblog.blogspot.com/>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
