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
