[IoT] Improvements to device grouping to allow shared users (non admin ) to control the devices

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[IoT] Improvements to device grouping to allow shared users (non admin ) to control the devices

Ayyoob Hamza
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.


Thanks
Ayyoob Hamza
Senior Software Engineer
WSO2 Inc.; http://wso2.com
email: [hidden email] cell: <a href="tel:%2B94%2077%207779495" value="+94777779495" style="color:rgb(17,85,204)" target="_blank">+94 77 1681010

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [IoT] Improvements to device grouping to allow shared users (non admin ) to control the devices

sumedha rubasinghe
+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 <[hidden email]> 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.


Thanks
Ayyoob Hamza
Senior Software Engineer
WSO2 Inc.; http://wso2.com
email: [hidden email] cell: <a href="tel:%2B94%2077%207779495" value="+94777779495" style="color:rgb(17,85,204)" target="_blank">+94 77 1681010



--
/sumedha
m: +94 773017743
b :  bit.ly/sumedha

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [IoT] Improvements to device grouping to allow shared users (non admin ) to control the devices

Chathura Ekanayake
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 <[hidden email]> 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 <[hidden email]> 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.


Thanks
Ayyoob Hamza
Senior Software Engineer
WSO2 Inc.; http://wso2.com
email: [hidden email] cell: <a href="tel:%2B94%2077%207779495" value="+94777779495" style="color:rgb(17,85,204)" target="_blank">+94 77 1681010



--
/sumedha
m: <a href="tel:+94%2077%20301%207743" value="+94773017743" target="_blank">+94 773017743
b :  bit.ly/sumedha


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [IoT] Improvements to device grouping to allow shared users (non admin ) to control the devices

Chathura Ekanayake
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.


Thanks
Ayyoob Hamza
Senior Software Engineer
WSO2 Inc.; http://wso2.com
email: [hidden email] cell: <a href="tel:%2B94%2077%207779495" value="+94777779495" style="color:rgb(17,85,204)" target="_blank">+94 77 1681010



--
/sumedha
m: <a href="tel:+94%2077%20301%207743" value="+94773017743" target="_blank">+94 773017743
b :  bit.ly/sumedha



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [IoT] Improvements to device grouping to allow shared users (non admin ) to control the devices

Ayyoob Hamza
@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.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [IoT] Improvements to device grouping to allow shared users (non admin ) to control the devices

Srinath Perera-3
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 <[hidden email]> 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.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
============================
Srinath Perera, Ph.D.
   http://people.apache.org/~hemapani/
   http://srinathsview.blogspot.com/

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [IoT] Improvements to device grouping to allow shared users (non admin ) to control the devices

Malintha Fernando-3
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 <[hidden email]> 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 <[hidden email]> 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.


_______________________________________________
Architecture mailing list
[hidden email]
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

https://wso2.com/signature





_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [IoT] Improvements to device grouping to allow shared users (non admin ) to control the devices

Ayyoob Hamza
 
1). Provide a way to map feature-permissions for the device types that are being created using the API.
we can allow this capability to be used for the pluggable device type but I think we cannot allow to create new permissions during runtime, since this permission hierarchy is visible to all tenants. Either we need to have a default permission or need to stick with the existing permission during the pluggable device type mode.

2). Implement the feature-permission mapping using the device type interface.
This is why I suggested to use it along with the feature definition. Is this what you meant or can you please explain on which interface.



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Loading...