Hi all, WDYT of a simple solution like this. We allow anyone who has subscriber role to read/write/delete (i.e. 7 in our permission model) their own comments. If the admin role needs the same permission, we can set 7 for admin role as well. Everyone else gets just read (i.e. 4.)
Thanks, Bhathiya 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 > > -- *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
