Hi,
We have a little concern regarding the permission check in OAuth secured
APIs in APPM.
Currently, all the available APIs are attached with relevant OAuth 2
scopes, but there are some cases where we cannot manage permissions using
scopes only.
For example, in application lifecycle change API, we need to check user
permissions in different criterias. Required permission to change the
lifecycle state of a mobile/webapp depends on the current state.
ie: The users with Internal/creator is allowed to perform the lifecycle
action 'Submit for Review' and change the state into 'In-review'. But rest
of the lifecycle state changes are allowed for users with
'Internal/publisher'. Below is the API definition.
URL : http://localhost:9763/api/appm/publisher/v1.0/apps
/{appType}/change-lifecycle
HTTP Methos : POST
URI Params : appId, action (ie: Submit for Review, Approve, Publish,Reject
..)
Thus we cannot achieve this permission check by attaching scopes with the
lifecycle change API, since there's a confusion in scope-role mapping.
(Current scope mapping is scope-role mapping : 'appm:publish' --> admin,
Internal/publisher. But this mapping cannot be applied for 'Submit for
Review' state change since its allowed to perform by 'Internal/creator')
We have two options to overcome this problem.
1. Remove scopes from lifecycle change API and manage permission check
in code level
2. Avoid using a common api for all lifecycle changes and maintain
different API resources for different lifecycle actions which require
different permissions. So different scopes can be assigned to each API.
What would be the best option? You suggestions and comments are highly
appreciated.
Thanks
On Tue, Apr 26, 2016 at 7:49 PM, Manuranga Perera <[email protected]> wrote:
> agreed Gayan.
> If we have following, it will be clearer. I changed 'apps' to '
> installations'
>
> DELETE http://localhost:9763/api/appm/storeadmin/v1.0/users/
> admin/installations/cec2027d-2dd6-4826-97c5-33be4eb83ae1
>
> On Tue, Apr 26, 2016 at 12:33 AM, Gayan Gunarathne <[email protected]>
> wrote:
>
>>
>>
>> On Mon, Apr 25, 2016 at 6:48 PM, Manuranga Perera <[email protected]> wrote:
>>
>>> DELETE is verb to un-link resources.
>>> Eg: DELETE /user/starred/manu/product-appm [1] will un-link me form
>>> appM. But it doesn't mean AppM repo will be deleted.
>>>
>>
>> See the url here. That make sense it deletes the starred with
>> manu/product-appm.
>>
>> With the rest, if we define the resources named well, that API is
>> intuitive and easy to use. If we defined the resources naming poorly, that
>> same API can feel awkward and be difficult to use and understand.
>> We need to consider http verb with the resource naming when creating the
>> rest api.
>>
>>
>>>
>>> [1]
>>> https://developer.github.com/v3/activity/starring/#unstar-a-repository
>>>
>>> On Mon, Apr 25, 2016 at 6:55 AM, SajithAR Ariyarathna <[email protected]
>>> > wrote:
>>>
>>>> [+ Frank]
>>>>
>>>> On Mon, Apr 25, 2016 at 11:49 AM, SajithAR Ariyarathna <
>>>> [email protected]> wrote:
>>>>
>>>>> ... "uninstall" is NOT a REST, even though it looks like REST.
>>>>>
>>>>> "uninstall" does not looks like REST. It looks like RPC.
>>>>>
>>>>> On Mon, Apr 25, 2016 at 10:43 AM, Ruwan Abeykoon <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> I disagree Manu, The point is this is not "DELETE" action on a
>>>>>> "resource". This is an action to remove a link between two resources. But
>>>>>> one oth that "Resource" is just a virtual resource(which is not under
>>>>>> control of the system). So I think having DELETE HTTP verb is wrong in
>>>>>> this.
>>>>>>
>>>>>> Cheer,
>>>>>> Ruwan
>>>>>>
>>>>>> On Mon, Apr 25, 2016 at 10:36 AM, Manuranga Perera <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> I think, even if it's not immediately affected (asynchronous), you
>>>>>>> still have to use the correct HTTP verb.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Architecture mailing list
>>>>>>> [email protected]
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *Ruwan Abeykoon*
>>>>>> *Architect,*
>>>>>> *WSO2, Inc. http://wso2.com <http://wso2.com/> *
>>>>>> *lean.enterprise.middleware.*
>>>>>>
>>>>>> email: [email protected]
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> [email protected]
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sajith Janaprasad Ariyarathna
>>>>> Software Engineer; WSO2, Inc.; http://wso2.com/
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sajith Janaprasad Ariyarathna
>>>> Software Engineer; WSO2, Inc.; http://wso2.com/
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> [email protected]
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> With regards,
>>> *Manu*ranga Perera.
>>>
>>> phone : 071 7 70 20 50
>>> mail : [email protected]
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> Gayan Gunarathne
>> Technical Lead, WSO2 Inc. (http://wso2.com)
>> Committer & PMC Member, Apache Stratos
>> email : [email protected] | mobile : +94 775030545 <%2B94%20766819985>
>>
>>
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : [email protected]
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Thilini Shanika
Software Engineer
WSO2, Inc.; http://wso2.com
20, Palmgrove Avenue, Colombo 3
E-mail: [email protected]
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
