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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >> >>> Hi Sam, >>> >>> Thanks for the clarification. >>> >>> On Thu, Aug 4, 2016 at 12:34 PM, Sam Sivayogam <[email protected]> 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 <[email protected]> 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 <[email protected]> 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: [email protected] <[email protected]> | 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: [email protected] <[email protected]> | Web: www.wso2.com >>>>> <http://lk.linkedin.com/in/milanharinduperera> >>>>> <https://wso2.com/signature> >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> [email protected] >>>>> 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: [email protected] <[email protected]> | Web: www.wso2.com >>> <http://lk.linkedin.com/in/milanharinduperera> >>> <https://wso2.com/signature> >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> Regards, >> >> Chatura Dilan Perera >> *Associate Tech Lead** - WSO2 Inc.* >> www.dilan.me >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
