Hi Ayyoob, +1 for the idea. In my understanding, we need to consider following two aspects for the implementation with the new pluggable device type API.
1). Provide a way to map feature-permissions for the device types that are being created using the API. 2). Implement the feature-permission mapping using the device type interface. In order to support the former, we need to send the mapping with the json payload and perform the addition of the permission to the tree at the API level, whereas the latter has to be performed when the device-type plugin is picked by the server. Please correct me if I have misunderstood anything. Regards, Malintha On Tue, May 9, 2017 at 1:44 PM, Srinath Perera <[email protected]> wrote: > adding Prabath. > > Don't we have this level of permission checks though identity components? > > If we have to implement this, then if we can keep the model with only > allow actions, it will simplify the model. > > --Srinath > > On Sat, May 6, 2017 at 12:45 AM, Ayyoob Hamza <[email protected]> wrote: > >> @Sumedha, >> Yes, it does in the context of the API. we can use the same permissions >> in the feature. The issue is that the permission in the API does not get >> propagated to the device context. >> >> @Chathura >> >>> What does it mean if a role R1 has access to device group G1, but >>> doesn't have permission to any feature of devices in G1? One option is to >>> allow such roles to only get information+status of devices. >>> >>> +1, we could allow the user to view the basic device info and properties. >> >> >>> I think we have to maintain following mappings to support this >>>> permission model (most of them are currently in the DB): >>>> >>>> device -> device group >>>> feature -> permission (is this coming from the device type xml file?) >>>> >>> permission -> role >>>> user -> role >>>> device group -> role >>>> >>> Yes, everything except feature -> permission is currently stored in the >> db. The changes I proposed will rely on the standard device type plugin >> interfaces. The implementation of that interface is currently either based >> on the file/java code but we can make this information to be stored in the >> DB, We can do this with the changes that we are planning todo on the DAO >> layer to add device type through the api. >> >> >>> >>>> I think the permission evaluation model is to allow an action, if it is >>>> allowed by at least one path. i.e. if device D1 belongs to groups G1 and >>>> G2, and user U1 belongs to roles R1 and R2, if R2 is allowed to access G1, >>>> U1 is allowed to access D1 (although R1 is not allowed to access G2). >>>> >>> Yes, This is how the evaluation is done in [1] but its not been used. >> >> >>> We also have to decide whether we are only supporting allow action or we >>>> want support deny action as well (e.g. role R1 is denied from accessing >>>> device group G2). If we support that, we have to enforce a precedence among >>>> allow and deny actions. IMO not supporting deny action is ok as it will >>>> complicate the permission evaluation. >>>> >>> In the current grouping implementation we only support allow action >> capability but this implicitly tackle the deny action(e.g role R1 is not >> assigned to group G2). In some usecases it might be more practical to have >> only deny action rather than the allow action. But this would complicate >> the model as you have mentioned. >> >> [1] https://github.com/wso2/carbon-device-mgt/blob/master/co >> mponents/device-mgt/org.wso2.carbon.device.mgt.core/src/ >> main/java/org/wso2/carbon/device/mgt/core/authorization/Devi >> ceAccessAuthorizationServiceImpl.java#L197 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > ============================ > Srinath Perera, Ph.D. > http://people.apache.org/~hemapani/ > http://srinathsview.blogspot.com/ > -- *Malintha Fernando* Software Engineer | WSO2 Mobile : +94 718874922 Blog : http://blog.malintha.org [image: https://wso2.com/signature] <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
