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.
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 <ayy...@wso2.com> 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: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495> > > On Tue, May 9, 2017 at 10:01 AM, Ayyoob Hamza <ayy...@wso2.com> 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: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495> >> >> On Tue, May 9, 2017 at 9:51 AM, Mushthaq Rumy <musht...@wso2.com> 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 <prasa...@wso2.com> >>> 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 <pubu...@wso2.com> >>>> wrote: >>>> >>>>> + Adding architecture mail group >>>>> >>>>> On Mon, May 8, 2017 at 11:59 PM, Pubudu Gunatilaka <pubu...@wso2.com> >>>>> 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 <fazl...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, May 8, 2017 at 3:59 PM, Ishara Cooray <isha...@wso2.com> >>>>>>> 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 <fazl...@wso2.com> >>>>>>>> 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> >>>>>>>>> fazl...@wso2.com >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thanks & Regards, >>>>>>> >>>>>>> Fazlan Nazeem >>>>>>> >>>>>>> *Senior Software Engineer* >>>>>>> >>>>>>> *WSO2 Inc* >>>>>>> Mobile : +94772338839 >>>>>>> <%2B94%20%280%29%20773%20451194> >>>>>>> fazl...@wso2.com >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *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 >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> 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 : musht...@wso2.com >>> WSO2, Inc.; http://wso2.com/ >>> lean . enterprise . middleware. >>> >>> <http://wso2.com/signature> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Nuwan Dias Software Architect - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
