Access control

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 to the resource type (using user roles/actors)
• Access to the resource tenant and guest tenants (using the user's tenant)
• Access to the resources owner (using the user accessing the resource)

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

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. Be careful with this option: an observation that reaches the system and triggers this kind of reasoners may affect things that span across all the tenants subscribed to the activity. It's the responsibility of the tenant to be sure that she understands the risks and this is exactly what she wants to do.