Hi Nuwan, The responsibility of this authorization check could be assigned to either one of the layers that you have mentioned. Currently, we have assigned this responsibility to API layer of the backend system.
Cheers, Dilan. *Dilan U. Ariyaratne* Senior Software Engineer WSO2 Inc. <http://wso2.com/> Mobile: +94766405580 <%2B94766405580> lean . enterprise . middleware On Tue, Aug 9, 2016 at 8:33 AM, Nuwan Dias <nuw...@wso2.com> wrote: > Whose responsibility is it to decide what details to return in the > response based on the user who's requesting it? Is it the fronting API's > responsibility to decide this or should it be the core back-end of the > Application who should be deciding who gets what? > > On Tue, Aug 9, 2016 at 6:47 AM, Dilan Udara Ariyaratne <dil...@wso2.com> > wrote: > >> Adding the thread to architecture, as this proposes an architectural >> change to existing OAuth scopes @ APIM level. >> >> Regards, >> Dilan. >> >> *Dilan U. Ariyaratne* >> Senior Software Engineer >> WSO2 Inc. <http://wso2.com/> >> Mobile: +94766405580 <%2B94766405580> >> lean . enterprise . middleware >> >> >> On Tue, Aug 9, 2016 at 6:30 AM, Dilan Udara Ariyaratne <dil...@wso2.com> >> wrote: >> >>> Hi Sam, >>> >>> I also think that Chathura is making a valid point here. >>> >>> For example, let's take the exact problem that EMM APIs do have >>> currently. >>> >>> I am considering GET /devices API here. For this API, we do have a >>> requirement to compile two responses >>> based on the type of user accessing the API. >>> >>> [1] If he is simply a device owner, he would only get the details of his >>> own devices. >>> [2] If he is an admin user, he would get the facility of retrieving all >>> the devices for that particular tenant. >>> >>> Since we can currently map only one scope with an API endpoint, that can >>> only be useful in verifying whether the particular user is capable >>> of accessing the API endpoint or not. This one-to-one level of API >>> scoping is not enough in identifying to >>> which of the above two responses, the user is authorized to access. >>> >>> If we had one-to-many level of API scoping, the story is different. >>> Then we can add two scopes like, get-owning-devices and get-all-devices >>> to the API, let a user access the API first by having either of two scopes. >>> Next, we can simply decide what response to be authorized based on which >>> of the two scopes, user is having. >>> >>> Since we do not currently have this facility of one-to-many level of API >>> scoping, to achieve the same functionality, we have now >>> got to think of other alternatives. Two such alternatives are: >>> >>> [1] Splitting the GET /devices API to two different APIs such that each >>> would cater one of the above two responses >>> and bring in the mentioned scopes to each of them separately: >>> >>> Although this is doable, this seems like duplicating >>> the same business logic in multiple APIs again and again. >>> >>> [2] Introducing a predefined role such as get-all-devices and validate >>> what response to be compiled based on that. >>> If the user accessing the API has this role, in addition to the assigned >>> API scope, he would get the facility of retrieving all the devices >>> for that particular tenant or otherwise,only get the details of his own >>> devices: >>> >>> Although this also seems doable, now we are simply in a process of >>> complicating permission management side of our application. >>> Since the capability of retrieving details of all devices is already >>> provided by a predefined role, now we do not have the >>> luxury of creating one single role having the same capability + another >>> set of capabilities simply because of the fact that a role cannot be >>> assigned to another role. >>> With this limitation, as of now if an administrator wants to assign a >>> user the capability of retrieving details of all devices + another set >>> of capabilities, >>> he cannot simply do that by assigning the user a single role, instead he >>> would need to assign at least two roles. This could get even worse >>> if we have the same issue for many other APIs as well. All this is >>> because we are violating the fundamental principals >>> and trying to authorize capabilities of our application directly via >>> roles instead of scopes or permissions. >>> >>> Cheers, >>> Dilan. >>> >>> >>> >>> *Dilan U. Ariyaratne* >>> Senior Software Engineer >>> WSO2 Inc. <http://wso2.com/> >>> Mobile: +94766405580 <%2B94766405580> >>> lean . enterprise . middleware >>> >>> >>> On Mon, Aug 8, 2016 at 2:08 PM, Chathura Dilan <chathu...@wso2.com> >>> wrote: >>> >>>> Hi Sam, >>>> >>>> Sometimes based on the scopes we might need to authorize the APIs to >>>> get different responses. >>>> >>>> Eg: Facebook scopes [1]. At the login we can send multiple scopes, >>>> generate the token and authorize an API based on scopes. >>>> >>>> It is not possible if only one scope is assigned to one API (resource). >>>> >>>> IMO scopes should be initially designed when the APIs are designed >>>> regardless of the roles that they would be attached to. >>>> >>>> [1] - https://developers.facebook.com/docs/facebook-login/permissions >>>> >>>> >>>> >>>> On Thu, Aug 4, 2016 at 1:41 PM, Milan Perera <mi...@wso2.com> wrote: >>>> >>>>> Hi Sam, >>>>> >>>>> Thanks for the clarification. >>>>> >>>>> On Thu, Aug 4, 2016 at 12:34 PM, Sam Sivayogam <s...@wso2.com> wrote: >>>>> >>>>>> Hi Milan, >>>>>> >>>>>> In APIM scopes are there to give access controls based on user roles. >>>>>> A scope can contain multiple user roles so if you want to block multiple >>>>>> roles add those roles to a* single scope *and assign to the >>>>>> particular resource. IMO there is no need to create multiple scopes with >>>>>> different roles and assigning it to the same resource, when you can >>>>>> already >>>>>> create a scope with multiple roles. >>>>>> >>>>>> Thanks, >>>>>> Sam >>>>>> >>>>>> On Thu, Aug 4, 2016 at 12:25 PM, Milan Perera <mi...@wso2.com> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> While going through the code I found that URITemplate class has an >>>>>>> attribute to store multiple scopes. >>>>>>> >>>>>>> package org.wso2.carbon.apimgt.api.model; >>>>>>> >>>>>>> >>>>>>> public class URITemplate implements Serializable { >>>>>>> *...* >>>>>>> private Scope scope; >>>>>>> private List<Scope> scopes = new ArrayList(); >>>>>>> >>>>>>> Can we use this scopes attribute to do the $subject? >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> >>>>>>> On Thu, Aug 4, 2016 at 12:09 PM, Milan Perera <mi...@wso2.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Is $subject possible? >>>>>>>> I noticed that $subject capability is limited in UI. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> -- >>>>>>>> *Milan Perera *| Software Engineer >>>>>>>> WSO2, Inc | lean. enterprise. middleware. >>>>>>>> #20, Palm Grove, Colombo 03, Sri Lanka >>>>>>>> Mobile: +94 77 309 7088 | Work: +94 11 214 5345 >>>>>>>> Email: mi...@wso2.com <ar...@wso2.com> | Web: www.wso2.com >>>>>>>> <http://lk.linkedin.com/in/milanharinduperera> >>>>>>>> <https://wso2.com/signature> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Milan Perera *| Software Engineer >>>>>>> WSO2, Inc | lean. enterprise. middleware. >>>>>>> #20, Palm Grove, Colombo 03, Sri Lanka >>>>>>> Mobile: +94 77 309 7088 | Work: +94 11 214 5345 >>>>>>> Email: mi...@wso2.com <ar...@wso2.com> | Web: www.wso2.com >>>>>>> <http://lk.linkedin.com/in/milanharinduperera> >>>>>>> <https://wso2.com/signature> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Dev mailing list >>>>>>> Dev@wso2.org >>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Sam Sivayogam* >>>>>> >>>>>> Software Engineer >>>>>> Mobile : +94 772 906 439 >>>>>> Office : +94 112 145 345 >>>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>* >>>>>> lean.enterprise.middleware. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Milan Perera *| Software Engineer >>>>> WSO2, Inc | lean. enterprise. middleware. >>>>> #20, Palm Grove, Colombo 03, Sri Lanka >>>>> Mobile: +94 77 309 7088 | Work: +94 11 214 5345 >>>>> Email: mi...@wso2.com <ar...@wso2.com> | Web: www.wso2.com >>>>> <http://lk.linkedin.com/in/milanharinduperera> >>>>> <https://wso2.com/signature> >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> Dev@wso2.org >>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> >>>> Chatura Dilan Perera >>>> *Associate Tech Lead** - WSO2 Inc.* >>>> www.dilan.me >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> Dev@wso2.org >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >> > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : nuw...@wso2.com > Phone : +94 777 775 729 >
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
