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 <m...@wso2.com> 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 <gay...@wso2.com> > wrote: > >> >> >> On Mon, Apr 25, 2016 at 6:48 PM, Manuranga Perera <m...@wso2.com> 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 <sajit...@wso2.com >>> > wrote: >>> >>>> [+ Frank] >>>> >>>> On Mon, Apr 25, 2016 at 11:49 AM, SajithAR Ariyarathna < >>>> sajit...@wso2.com> 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 <ruw...@wso2.com> >>>>> 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 <m...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> I think, even if it's not immediately affected (asynchronous), you >>>>>>> still have to use the correct HTTP verb. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> Architecture@wso2.org >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Ruwan Abeykoon* >>>>>> *Architect,* >>>>>> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >>>>>> *lean.enterprise.middleware.* >>>>>> >>>>>> email: ruw...@wso2.com >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> Architecture@wso2.org >>>>>> 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 >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> With regards, >>> *Manu*ranga Perera. >>> >>> phone : 071 7 70 20 50 >>> mail : m...@wso2.com >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> Gayan Gunarathne >> Technical Lead, WSO2 Inc. (http://wso2.com) >> Committer & PMC Member, Apache Stratos >> email : gay...@wso2.com | mobile : +94 775030545 <%2B94%20766819985> >> >> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > With regards, > *Manu*ranga Perera. > > phone : 071 7 70 20 50 > mail : m...@wso2.com > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > 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: tgtshan...@gmail.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture