Function Description For The Sub Account Of B (Big Account )

Opening the function of subaccount of platform B (large account) the main is aimed at controlling the B (large account) mode developer account permissions. With this function, the sub account can be created within the permissions of developer account, and different permission is assigned to the corresponding subaccount

Why use sub account

One of the core issues that a sub account needs to address is how to safely authorize other people to access devices without exposing the AccessToken of the B (big account) model developer. Because once the developer's AccessToken is exposed, there is a security risk, and others can have access to all of the device resources of the developer.

However, the sub account function is a long-term effective mechanism of access control, and by separating sub account with different permissions, different permissions will be assigned to different users. In this case, once the sub account leak ,it will not cause global information disclosure.

Basic concepts

The following is a brief explanation of some basic concepts: sub account: It is a sub account created from developer accounts with the EZVIZ open platform. when creating sub account ,the developer can set different permission and passwords .when created, each sub account has a ID.

• Authorization policy: a rule used to define permissions, such as previewing a device.
• Resource: a resource that a user can access, such as a device with a serial number of 469631729, or a first channel of a device with a serial number of 469631729.

Application scenarios

If you buy some EZVIZ devises or other Hikvision devises with EZVIZ protocol and all the devises are used with the account of developer ,the users who have an access to these devises will be exposed to using the AccessToken created from the developer account Here's the problem: you can't control the privileges of the devices that a particular user can access.

Here is the solution: rights control can be achieved through the function of sub account. The developer account is called the primary account while account recreated is called a sub account. The sub account can only use the operations and equipment resources authorized by the master account.

Application scenarios of sub account

the scene of educational institution video surveillance system is taken for example. a kindergarten has ten classrooms, and each classroom has 2 EZVIZ cameras, while the kindergarten administrator has these 20 EZVIZ equipment ownership. An APP has been developed and integrated OpenSDK in a The kindergarten, and with the help of this APP, these parents will be able to see video in the class. Once the parents register on this APP ,the kindergarten administrators assign corresponding classroom permissions to the parents to see own their children ,and PTZ control, video encryption can not be operated. Description of the sub account is shown below:

Details of the scheme are described below：

1. User register on this APP . App users are terminal ones ,and they are user of developer. And they have nothing to do with EZVIZ cloud or its platform account.

2. Create sub accounts. For every valid App users, App Server can define each App user access permissions (described by the Policy grammar); for every App user has access to specify a sub account, if there is no, it need to create a specified access sub accounts. correspondence between App users and sub accounts will be saved in App server.

   The sub account can be created with the open platform of EZVIZ via an interface, and terminal user are not aware of the sub account .

   In this scenario, a sub account of "" parents in classroom A " will be created and authorized to check theinformation of devices and to live view and playback. However, the sub account just have the access to C6(519928976)、C2C(470686804)

   {
    "Statement": [
        {
            "Permission": "Get,Real,Replay",
            "Resource": [
                "dev:519928976",
                "dev:470686804"
            ]
        }
    ]
   }
   

3. log in with account

4. The App Server recognize the corresponding sub account of this App user,and request the EZVIZ cloud to offer the platform and gain a Access Token in class A
5. the opening platform of EZVIZ give back a valid voucher with expiration time and Access Token to App Server.
6. App Server returns the access credentials to the Client App. while Client App can buffer this Access Token. When Access Token fails, Client App needs to apply for a new Access Token from App Server.
7. Client App uses Access Token to request EZVIZ opening platform API (including the Open SDK interface and the Http interface). EZVIZ opening platform verifies that the sub account has access to the device in accordance with the Access Token in the request parameter, and only the requests that meet the minimum permissions required by the API interface are allowed. If the user queries the device list, the cloud platform will only return the device information gained by sub account with corresponding access

In this scenario, the user will check device list, and cloud platform only return back the information of equipment C6 (519928976), C2C (470686804); if other equipment or this 2 equipment is operated with the PTZ control, video encryption, cloud platform will return to the error code “no access”

Sub account authorization policy (Policy) configuration

There is a Statement in Policy (one can have multiple Statement in Policy). And the Statement specifies the corresponding Permission, Resource.
The following is an example of an authorization policy (Policy):

{
    "Statement": [
        {
            "Permission": "Get,Update,DevCtrl",
            "Resource": [
                "dev:469631729",
                "cam:544229080:1"
            ]
        },
        {
            "Permission": "Get,Real",
            "Resource": [
                "dev:470686804"
            ]
        }
    ]
}

The Policy licensed 469631729, 544229080, 470686804 and other equipment resources under the developer EZVIZ account, and it supported Get, Update, DevCtrl, and Real respectively.

Configuration details

Statement

“Statement” describes the authorization semantics, and each contains descriptions of Permission and Resource. Each request system will check matches one by one, and if the matches are successful, the request can pass the authentication. If none matches successfully, the request will be denied .

Permission

Includes the following permissions:

Comment: in this version, the sub-account does not have add/delete device permission; sub-account can send request of add/delete device to developer, developer add/delete device.

Resource

Resource usually means the operation object, like device, channel, we use the following format to name the resource, {resourceType}:{resourceId}；

• resourceType: the type of resource, there are only two types, dev(device), cam(channel)；
• resourceId：the ID of resource, resourceId of dev type is serial number, resourceId of cam is serial number: channel number.

Subordinate relations

Cam resource belongs to dev resource, the sub-account’s permission to dev resource can pass to cam resource. For instant, there are two resources, dev: 544229080 and cam: 544229080:1, cam: 544229080:1 belongs to dev: 544229080; If the developer give the real permission of dev: 544229080 resource to sub-account, then this sub-account has the real permission for cam: 544229080:1.