Difference between revisions of "Access control"

From AMTech WikiDocs
Jump to: navigation, search
(→‎Roles)
 
(18 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
Access control is applied based on the info of the resource being accessed, validating it against the info of the user accessing the resource. The verifications for access control are :
+
Access control is applied based on the info of the resource being accessed. This info is validated against the info of the user accessing the resource.  
−
* Access to the resource type (using user roles/actors)
+
When a user wants to perform a CRUD operation on a resource, 3 levels of security are applied
−
* Access to the resource tenant and guest tenants (using the user's tenant)
+
* Security checks at the resource type level: User must have access to the resource type (using user roles/actors)
−
* Access to the resources owner (using the user accessing the resource)
+
* Security checks at the tenant level: User must belong to the resource tenant or to a tenant included in the resource guest tenants. If the user tenant is a guest tenant of the resource, the user can only perform READ operations on the resource.
 +
* Security checks at the user level (applied only if the actor has the checkUser flag) :
 +
** User must be the owner or guest user of the resource. It can only perform the CRUD operations included in the actor.
 
This validations are performed in order.
 
This validations are performed in order.
  
Line 18: Line 20:
 
* They are associated to users
 
* They are associated to users
 
* They are system managed.  
 
* They are system managed.  
−
* There are 2 main roles : activityCreator (or just creator for simplicity) and follower. All users have one and only one of these two roles.
+
* There are two main roles:  
−
* Users with the role creator will have access to thing types and observation types
+
** activityCreator (or just creator for simplicity)  
−
**the admin tenant can remove or add members using the options team and invite respectively
+
** follower  
−
**PaaS functionality
+
* All users have one and only one of these two roles. Meaning a user cannot be follower and creator at the same time.
−
* Users with the roles follower will have the access their actors define (See [[Access control#Actors|Actors]])
+
* Between each one of these two roles we can distinguish between admins and invited users to tenants. It means that we can have:
−
**the admin tenant can remove or add members using the options team and invite respectively
+
** admin creator of a tenant
−
**SaaS configuration functionality
+
** invited creator to a tenant
 +
** admin follower of a tenant
 +
** invited follower to a tenant
 +
 
 +
=== Creators ===
 +
Users with the role creator are designed to configure activities in the system (PaaS functionality). They will have exclusive access to:
 +
* Thing types owned by them in addition to all published thing types.
 +
* Observation types whether they are owned by him or not.
 +
* Activities with the possibility of create new activities and publish them.
 +
* Create new root topics.
 +
 
 +
''Admin creators'' are those that subscribe a tenant for the first time into the sytem. In addition to the previously mentioned permissions, they will be able to manage their team by:
 +
* Adding members to their team by using the ''invite'' option.
 +
* Removing members from their team by using the ''team'' option.
 +
 
 +
{{Template:Note|A user can be admin creator for a tenant and invited creator to other tenants as well.}}
 +
 
 +
=== Followers ===
 +
Users with the role follower are designed to be the users of services in the system (SaaS configuration functionality). They will mainly have the permissions defined by their actors (See [[Access control#Actors|Actors]]). They will be able to:
 +
* Create, modify or delete things belonging to one of the thing types they have access to (based on actors).
 +
* Create, modify or delete simulations belonging to one of the observation types they have access to (based on actors).
 +
* Send simulations to the sensor's network.
 +
 
 +
Similar to ''admin creators'', ''admin followers'' for a tenant are those that introduce a new tenant to the system. They will be able to manage their team by:
 +
* Adding members to their team by using the ''invite'' option.
 +
* Removing members from their team by using the ''team'' option.
 +
* Editing the list of actors a member has as a subset of the available actors to the admin follower.
 +
 
 +
{{Important remark|You cannot use admin followers in the authentication configuration of M2MBridge running instances. This is what invited followers are designed for. The access control defined by invited follower's actors allows to establish a more granulated access and defines the exact things a M2MBridge running instance has access to.}}
 +
 
 +
{{Note|A user can be admin follower for a tenant and invited follower to other tenants as well.}}
  
 
== Actors for things and observations ==
 
== Actors for things and observations ==
Line 43: Line 75:
 
**Update (update resources of this type)
 
**Update (update resources of this type)
 
**Delete (delete resources of this type)
 
**Delete (delete resources of this type)
−
;if Check user is flag the polices will enforce that the user must own the resource to CRUD it
+
{{Note|If Check User ID option is checked then the polices will enforce that the user must own the resource to CRUD it.}}
 
[[File:Actor-polices.png|980px|thumbnail|center|Actor policies]]
 
[[File:Actor-polices.png|980px|thumbnail|center|Actor policies]]
  
Line 60: Line 92:
  
 
== Access control properties in resources ==
 
== Access control properties in resources ==
−
;Things and observations types have 4 properties to govern access control  
+
Things and observations types have 4 properties to govern access control  
 
*_tenant assigned by the DAP, value is set  to the tenant that creates the resource
 
*_tenant assigned by the DAP, value is set  to the tenant that creates the resource
 
*_user assigned by the DAP, value is set to the user that creates the resource
 
*_user assigned by the DAP, value is set to the user that creates the resource
 
*guesttenants can be assigned by the user that created the resource
 
*guesttenants can be assigned by the user that created the resource
 
*guestusers can be assigned by the user that created the resource
 
*guestusers can be assigned by the user that created the resource
−
 
−
== Access while executing observers in the reasoner's engine ==
 
−
Regarding security, there are two possibilities when you configure the execution of the observer in a reasoner:
 
−
* Use the security of the observation to restraint the things returned by the observer.
 
−
: In this case the tenant of the observation is used to restraint the set of things returned by the observer. This restriction is applied on resource's tenant, meaning that only the things owned by the tenant will be returned. This does not include the things shared with the tenant.
 
−
* Use the security of the service to restraint the things returned by the observer.
 
−
: In this case the tenants subscribed to the service are used to restraint the set of things returned by the observer.
 

Latest revision as of 11:27, 6 August 2018

Access control is applied based on the info of the resource being accessed. This info is validated against the info of the user accessing the resource. When a user wants to perform a CRUD operation on a resource, 3 levels of security are applied

  • Security checks at the resource type level: User must have access to the resource type (using user roles/actors)
  • Security checks at the tenant level: User must belong to the resource tenant or to a tenant included in the resource guest tenants. If the user tenant is a guest tenant of the resource, the user can only perform READ operations on the resource.
  • Security checks at the user level (applied only if the actor has the checkUser flag) :
    • User must be the owner or guest user of the resource. It can only perform the CRUD operations included in the actor.

This validations are performed in order.

How it works

Access control

Multitenancy

Amtech IoT platform is multitenant , with the goals of :

  • Protecting resources that belong to a tenant
  • Sharing resources among tenants based on the guesttenants/guestusers properties of the resources

Roles

Roles are resources that define the access control policies for the core resources.

  • They specify the HTTP operations allowed on a given resource type.
  • They are associated to users
  • They are system managed.
  • There are two main roles:
    • activityCreator (or just creator for simplicity)
    • follower
  • All users have one and only one of these two roles. Meaning a user cannot be follower and creator at the same time.
  • Between each one of these two roles we can distinguish between admins and invited users to tenants. It means that we can have:
    • admin creator of a tenant
    • invited creator to a tenant
    • admin follower of a tenant
    • invited follower to a tenant

Creators

Users with the role creator are designed to configure activities in the system (PaaS functionality). They will have exclusive access to:

  • Thing types owned by them in addition to all published thing types.
  • Observation types whether they are owned by him or not.
  • Activities with the possibility of create new activities and publish them.
  • Create new root topics.

Admin creators are those that subscribe a tenant for the first time into the sytem. In addition to the previously mentioned permissions, they will be able to manage their team by:

  • Adding members to their team by using the invite option.
  • Removing members from their team by using the team option.

Note: A user can be admin creator for a tenant and invited creator to other tenants as well.

Followers

Users with the role follower are designed to be the users of services in the system (SaaS configuration functionality). They will mainly have the permissions defined by their actors (See Actors). They will be able to:

  • Create, modify or delete things belonging to one of the thing types they have access to (based on actors).
  • Create, modify or delete simulations belonging to one of the observation types they have access to (based on actors).
  • Send simulations to the sensor's network.

Similar to admin creators, admin followers for a tenant are those that introduce a new tenant to the system. They will be able to manage their team by:

  • Adding members to their team by using the invite option.
  • Removing members from their team by using the team option.
  • Editing the list of actors a member has as a subset of the available actors to the admin follower.

Important remark: You cannot use admin followers in the authentication configuration of M2MBridge running instances. This is what invited followers are designed for. The access control defined by invited follower's actors allows to establish a more granulated access and defines the exact things a M2MBridge running instance has access to.

Note: A user can be admin follower for a tenant and invited follower to other tenants as well.

Actors for things and observations

Actors are resources that define access to specific thing types and notification types

  • They specify the HTTP operations allowed to the type
  • They are associated to users with the role follower via the subscription to a service or the invitation of new users
  • Actors can include a restriction to apply the access control using the target resource user (meaning that the access control will be applied verifying access to type, tenant and user)

Access to observation types is also defined by actors, in relation to the observation production configuration of the thing types. For a follower to have access to observations of a given type, the follower must have an actor that gives access to a thing type that produces this observation type.

Policies

A police encompasses

  • A Thing type
    • The set of CRUD operations that can be execute over the selected Thing type
    • Create (create a new resource of the type)
    • Read (read resources of this type)
    • Update (update resources of this type)
    • Delete (delete resources of this type)

Note: If Check User ID option is checked then the polices will enforce that the user must own the resource to CRUD it.

Actor policies

Tenants

  • All resources have associated with them the tenant that owns it (the tenant of the user that created the resource), and may also define the list of guest tenants that will have read access to the resource.
  • The tenant of a resource is automatically assigned when the resource is created and cannot be modified.
  • The list of guest tenants of a resource can be assigned by the user.

Users

  • The user id must be an email (to be redefined in future versions)
  • A user can belong to multiple tenants, it may have multiple actors, but it can have only one role (either activityCreator or follower)
  • Users are related to the resources regarding access control:
    • All resources have the user that owns it (the user that created the resource), and may also define the list of guest users, that will have access to the resource according to their actors.
    • The user of a resource is automatically assigned when the resource is created and cannot be modified.
    • The list of guest users of a resource can be assigned anytime.

Access control properties in resources

Things and observations types have 4 properties to govern access control

  • _tenant assigned by the DAP, value is set to the tenant that creates the resource
  • _user assigned by the DAP, value is set to the user that creates the resource
  • guesttenants can be assigned by the user that created the resource
  • guestusers can be assigned by the user that created the resource
Retrieved from "http://wiki.amtech.mx/mediawiki/index.php?title=Access_control&oldid=3778"