Hi Milan and Ayyoob, Mapping an application capability directly to a role, only complicates the permission management side of the same.
As this was initially dealt by a permission, ideally now, this should be dealt by a scope since we are now moving from carbon permission based approach to OAuth scope based approach for backend authorizations. But we do have concerns here. I will explain this by taking 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. Ideally, 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 the facility of one-to-many level of API scoping, to achieve the same functionality, we have now got to think of other alternatives. Three of 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 the missing scope externally to the existing model and doing the check with in the same API: This approach is debatable as it violates the current architecture of OAuth scopes @ APIM level. [3] 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. Cheers, Dilan. *Dilan U. Ariyaratne* Senior Software Engineer WSO2 Inc. <http://wso2.com/> Mobile: +94766405580 <%2B94766405580> lean . enterprise . middleware On Wed, Aug 3, 2016 at 11:50 AM, Ayyoob Hamza <[email protected]> wrote: > Milan, Please find my comments inline. > > *Ayyoob Hamza* > *Software Engineer* > WSO2 Inc.; http://wso2.com > email: [email protected] cell: +94 77 1681010 <%2B94%2077%207779495> > > On Wed, Aug 3, 2016 at 8:47 AM, Milan Perera <[email protected]> wrote: > >> Hi all, >> >> In CDMF, we are currently heading towards OAuth2 scope based >> authorization mechanism by revamping current carbon permission based >> authorization mechanism in order to support widely accepted standard for >> API authorization. >> >> As a result, we have to find a new way to do the $subject. So the problem >> is that when a particular role has the permission to invoke an API endpoint >> which is used to add an operation to a device, an user in that role can add >> that operation irrespective of his ownership to that device. >> >> For an example, lets say user A owns device D1 and he has the permission >> to invoke operation add APIs. Since he already has the permission to invoke >> APIs he can add operations by giving another device id like D2 even though >> it does not belong to that user. >> >> So the solution that was there before to overcome is that, we first check >> whether a particular user who execute this operation holds the ownership of >> the device or whether he/she is a device-mgt admin. Saying that, this >> device-mgt admin is just a carbon permission which a role should have in >> order to add operations to devices. >> >> Since we are moving to scopes based authorization, this carbon permission >> based check is not going work anymore. Therefor we should have to come up >> with ideas to do it better. >> >> Proposed suggestions >> >> 1. Use a special scope such as "device-mgt:admin" so that who has >> that scope can add operations to devices that do not belong to him. For >> that, once the scope validation is done, valid scopes are stored in a >> threadlocal variable and check the specific scope at the authorization >> module. >> >> Having a unique scope for only admin use case is bit blurry. I am not > clear on how we can restrict a user (not an admin) to access a device that > has been to shared to him and who has only specific set of device > management privileges(admin, viewing analytics, send operation.... etc). In > this case what I see is that we should not have a specific scope only for > admin user rather a specific scope structure > (device-mgt:<deviceType>:<deviceId>:<action> > eg :device-mgt:android:adfa32231111sdfsg:stats). The token issue service > should communicate with CDMF and validate before issuing the token. > Whenever a user calls an api then we should get the authorized scopes and > convert that into a authorised device context. However the problem > regarding this approach is that we should request a token whenever a user > wants to communicates with different set of devices. > > Use a pre-defined role such as "device-mgt-admin" so that user who is in > that role can do the operations. > +1 for this approach,This implementation is straight forward if we have > to handle admin use case separately which we can easily change by moving > the current implementation from permission check to role check in the > deviceAuthorizationService. However moving to above suggested approach > would be a better approach but not a straightforward implementation, > therefore it is better if we can do some kind of a POC. > > Please share your opinions on above or new suggestions are welcome. >> >> 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> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
