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.
On Fri, May 5, 2017 at 11:05 AM, Chathura Ekanayake <[email protected]> wrote: > 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 > > 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). > > 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. > > Regards, > Chathura > > On Fri, May 5, 2017 at 10:32 AM, Sumedha Rubasinghe <[email protected]> > wrote: > >> +1 to the idea. >> >> Permission to feature mapping is already happening within JAX-RS >> definition. Isn't t? >> >> On Fri, May 5, 2017 at 1:48 AM, Ayyoob Hamza <[email protected]> wrote: >> >>> Hi All, >>> >>> We can share a device group among the users with a specific set of >>> permissions(through a Role). However in the current implementation, Even if >>> the group is shared still the users in the group will not be able to >>> operate the device unless they have the admin permission. This restricts >>> scenarios that we can cover through the grouping capability. >>> >>> In the device access authorization implementation we have 3 level of >>> authorization checks[1]. >>> >>> 1. IsAdmin >>> 2. IsOwner >>> 3. IsAuthorizedThroughGroup >>> >>> In here the shared user falls into the 3rd level. >>> >>> In the grouping implementation, we have followed a fine-grained >>> permission model. This is to solve scenarios such as "An administrator >>> shares the POS terminal to a set of employees in a supermarket allowing >>> only to operate few capabilities in the device". >>> >>> In order for this to work, We need a permission to feature mapping and >>> also we have to assign that permissions to the group. In the current >>> implementation, we have not assigned any permission to the feature. But we >>> have allowed assigning permissions to the group through the role. >>> >>> Therefore in order to solve the disconnection between authorization >>> service and the device sharing model, I wanted to suggest to include the >>> permission as part of the feature definition. This way we can evaluate the >>> permission of the feature with the role that is assigned to the group. >>> >>> feature :{ code, name, description, *permission*} >>> >>> Please share your thoughts about this. >>> >>> [1] https://github.com/wso2/carbon-device-mgt/blob/master/co >>> mponents/device-mgt/org.wso2.carbon.device.mgt.common/src/ma >>> in/java/org/wso2/carbon/device/mgt/common/authorization/Devi >>> ceAccessAuthorizationService.java >>> >>> Thanks >>> *Ayyoob Hamza* >>> *Senior Software Engineer* >>> WSO2 Inc.; http://wso2.com >>> email: [email protected] cell: +94 77 1681010 <%2B94%2077%207779495> >>> >> >> >> >> -- >> /sumedha >> m: +94 773017743 <+94%2077%20301%207743> >> b : bit.ly/sumedha >> > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
