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
