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
