Skip to end of metadata
Go to start of metadata
The Internet of Things (IoT) is the next evolution of the Internet. Conceptually, the IoT is the ability to connect devices of any type (smartphones, home appliances, wearable devices, etc.) to the Internet network, allowing to collect, share and process data for various purposes and for an unlimited panel of diverse application areas: from home automation, health monitoring, security or smart cities, etc. Despite this diversity, all these applications share the need to securely store and process data, execute workflows and connect to other devices and/or applications such as social medias, CRM or ERP applications for example. All these needs are covered by Apstrata, which also expose the Devices API, catering thus for the necessity of IoT application developers to manage the devices that will be part of their application, either as consumers or as producers.

With Apstrata, you can build multi-user/device applications. In order to be able to read or write data to an apstrata account store, you have to be the Account Owner or you have to be registered as a User or a Device in the apstrata account. API requests signed with a Device signature are Device requests as opposed to owner requests which are signed with the account secret.

When you register with Apstrata, an account will be created for you. With each account creation, there is a default device Schema named "apsdb_device" that gets created. The purpose of this Schema is to give the owner the possibility of defining custom device profiles. Hence, an owner can add new fields, define permissions, and define validation rules for each field. When saving devices, custom device attributes can be set and validated automatically based on the rules defined for each one. The fields already defined in the default device Schema are required and should not be removed.

A Device entity is persisted as a Document in the apstrata account user directory Store, based on the Schema named "apsdb_device".

A Device can belong to zero or more Groups defining its read and write permissions.

A device can be suspended by calling SaveDevice and setting the system field "isSuspended" to true. A suspended device still exists in the system but is treated as if it was deleted. Any request made to Apstrata with this device will return an exception saying that the signature is invalid. The device can be reactivated by calling SaveDevice and setting the field "isSuspended" back to false. By default, the ACLs of this field are set in a way that only the owner of the account can suspend or un-suspend a device but you are free to change those ACLs by updating your device schema.

Note that owners will always have the permission to call the GetDevice and SaveDevice APIs, but Devices can only read or update their own profile Documents. In other words, the permissions defined in the Schema ACLs can only be used to restrict Devices from accessing their own profile Document or other Devices profile Documents.

For more details about schema definition, please refer to Document Schema Definition.


Default Device Schema (apsdb_device)

 

<!-- This is the default device schema. Feel free to modify it to your liking. 
    This schema follows all rules and restrictions as all other schemas, as do 
    the documents (devices) created out of it. However, it imposes the following 
    restrictions of its own: 1. The seven default fields (groups, name, id, 
    password, locale, isSuspended and token) are required. 2. This schema cannot be 
    deleted. Additionally, since this schema is used for device management, the 
    following ACLs are set by default upon creation of each new device document: 
    - document.readACL = id, creator - document.writeACL = id, creator 
    - deleteACL = nobody - required.readACL = nobody - required.writeACL = nobody 
    - requiredVisibles.readACL = id, creator - requiredVisibles.writeACL = 
    nobody - requiredEditables.readACL = id, creator - requiredEditables.writeACL 
    = id, creator You can specify your own ACLs upon device creation by passing 
    them as parameters to the SaveDevice API as described in the documentation. -->
<schema>
    <aclGroups>
        <aclGroup name="required">
            <read>nobody</read>
            <write>nobody</write>
            <fields>
                <field>isSuspended</field>
            </fields>
        </aclGroup>
        <aclGroup name="requiredVisibles">
            <read>creator</read>
            <write>nobody</write>
            <fields>
                <field>id</field>
                <field>groups</field>
                <field>token</field>
            </fields>
        </aclGroup>
        <aclGroup name="requiredEditables">
            <read>creator</read>
            <write>creator</write>
            <fields>
                <field>name</field>
                <field>password</field>
                <field>locale</field>
            </fields>
        </aclGroup>
        <defaultAcl>
            <read>creator</read>
            <write>creator</write>
        </defaultAcl>
        <schemaAcl>
            <read>creator</read>
            <write>creator</write>
            <delete>nobody</delete>
        </schemaAcl>
    </aclGroups>
    <fields>
        <field name="id" type="string" />
        <field name="name" type="string" />
        <field name="groups" type="string" />
        <field name="password" type="string" />
        <field name="locale" type="string" />
        <field name="isSuspended" type="string" />
        <field name="token" type="string" />
    </fields>
</schema>
  • No labels