Hi Mushthaq,
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?
>
Yes this will happen if we did not validate the user in the back end with
the logged in user when sending data to the REST API layer. We ca have a
user validation in between the database and REST API layer. Also we need to
send the authorize operation list(add, delete, update) to the front end to
facilitate front end implementation.
>
> 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
