Hi Frank, Thilini, Really sorry that i missed this thread and taking long time to reply.
As i understood this is more like a application implementation level thing and its not related to authentication and security. To be clear on this, security, authentication or authorization may depend on user credentials, access tokens etc. If we carefully analyze this requirement you need to do some filtering/checking based on current state of application(not entirely depend on auth data). So i think its better to move this to application(web service implementation). You may take user from message context do service implementation level checks. Thanks, sanjeewa. On Wed, Apr 27, 2016 at 3:12 PM, Frank Leymann <[email protected]> wrote: > Sanjeewa (or Prabath) may have guidance on this... > > > Best regards, > Frank > > 2016-04-27 11:11 GMT+02:00 Thilini Shanika <[email protected]>: > >> + Frank >> >> On Wed, Apr 27, 2016 at 2:36 PM, Thilini Shanika <[email protected]> >> wrote: >> >>> 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] >>> >>> >> >> >> -- >> Thilini Shanika >> Software Engineer >> WSO2, Inc.; http://wso2.com >> 20, Palmgrove Avenue, Colombo 3 >> >> E-mail: [email protected] >> >> > -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
