Thing in the future

Accueil > FAQ > Security

Security

An newly created avatar has no access restrictions, it’s a public avatar. To restrict access, you must attach an Access Control List (ACL) to it. An ACL is a set of rules defining the conditions necessary to read and/or write the properties of the avatar. For example, the ACL can specify that only a given user can read the avatar, or that a subgroup of users can modify a specific property. An ACL policy acts like a firewall filter.

In addition to the role management rules that define the actions that are allowed or denied to a user on a ressource, you can also use the access Lists (ACL) and security groups to define what can be done on an avatar.
To manage a group of users or avatars, the concept of security group has been implemented in Thing’in. A security group, composed of one or more users, can be used by an ACL. For exemple, an ACL attached to an avatar can specify that only Security Group SG1 users can modify the avatar’s geolocation property.

For more detailled information, see Thing’in wiki : https://wiki.thinginthefuture.com/#Security%20and%20Confidentiality

and a simple example : https://wiki.thinginthefuture.com/#Security%20groups%20and%20ACL%3A%20simple%20use%20case

A role is a collection of permissions that can be applied to users. By default, a newly created user in Thing’in will have the user role. To grant more permissions to tjat user, you have to be n admin user or a service-admin user. Below is the list of roles managed by Thing’in :

  • ADMIN : full right over all the resources. 
  • SUPERVISOR : observe the platform and user metrics. 
  • SERVICE-ADMIN : administrator of a 3rd party service. 
  • PROVIDER : avatar provider. 
  • USER : standard user.
  • Get your authentication token via Thing’in portal : menu Develop > Get my Thing in token.

    OR

    via Thing’in API
    GET https://coreapi.thinginthefuture.com/auth with in parameters a given list of domains |optional] , a liste scopes [optional] and the basic auth
    The scope could be a list of role names separated by comas OR a list of resource name:right separated by comas.
    Exemple 1 : provider,supervisor.
    Exemple 2 : resource.user.read:ALLOW,resource.user.list:ALLOW

  • OR

    Via swagger : menu Develop > Thing in APi reference > auth > GET /auth,