Hi Nuwan/Bhathiya, On Tue, May 9, 2017 at 10:19 AM, Nuwan Dias <nuw...@wso2.com> 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 <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 <+94%2077%20777%205729> > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > 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> fazl...@wso2.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
