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.
   2. Use a pre-defined role such as "device-mgt-admin" so that user who is
   in that role can do the operations.

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

Reply via email to