Difference between revisions of "Access control"
From AMTech WikiDocs
(→Roles) |
|||
| (50 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | Access control is applied based on the info of the resource being accessed | + | 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 |
| − | * | + | * 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. | This validations are performed in order. | ||
| + | |||
| + | == How it works == | ||
| + | [[File:Acess-control-how-it-works.jpg|850px|thumbnail|center|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 == | ||
| Line 10: | Line 20: | ||
* They are associated to users | * They are associated to users | ||
* They are system managed. | * They are system managed. | ||
| − | * There are | + | * 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 | ||
| − | == Actors == | + | === Creators === |
| − | Actors are resources that | + | Users with the role creator are designed to configure activities in the system (PaaS functionality). They will have exclusive access to: |
| − | * They specify the HTTP operations allowed | + | * 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 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 | * 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) | * 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 [https://en.wikipedia.org/wiki/Create,_read,_update_and_delete 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.}} | ||
| + | [[File:Actor-polices.png|980px|thumbnail|center|Actor policies]] | ||
== Tenants == | == Tenants == | ||
| − | * All resources have the tenant that owns it (the tenant of the user that created the resource), and may also define the list of guest 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 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. | * The list of guest tenants of a resource can be assigned by the user. | ||
== Users == | == Users == | ||
| − | * 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 id must be an email (to be redefined in future versions) |
| − | * The user of a resource is automatically assigned when the resource is created and cannot be modified. | + | * A user can belong to multiple tenants, it may have multiple actors, but it can have only one role (either activityCreator or follower) |
| − | * The list of guest users of a resource can be assigned anytime | + | * 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 | ||
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.
Contents
How it works
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.
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
