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
