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
