@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/components/device-mgt/org.wso2.carbon.device.mgt.core/src/main/java/org/wso2/carbon/device/mgt/core/authorization/DeviceAccessAuthorizationServiceImpl.java#L197
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
