Since a long time I’m trying to understand how the Sigfox right (ACL) works and stop affecting all the rights to my API access every time I’m creating a new one. More than that, when I’m working with clients or other LPWAn passionates I do not like requesting full access to the Sigfox backend to help them or integrate them in my backend.

So, it was a nice opportunity to tale a look to the ACL and document them with an overall overview instead of the detailed information you can get from the User Creation screen. (You may note that this documentation can’t be accessed from the API access creation screen but the groups are the same as for users).

Basically in the group I have access to I saw 2 kind of profiles:

• Global profiles :

The global profiles are predefined profiles with a large group of access already established. The main one are:

– DEVICE_MANAGER[R]: This group is proposing an overall access to the information but restrict them to READ. You can’t create anything with this account but basically see everything. This account is secure for read as you can’t access some important information (even in read) like the PAC device information. (You can’t transfer a device to another account). Another limitation is about the detailed on received uplink (SNR, frequencies, out-of-band, repeat, geoloc payload) are not accessible, even in read.

– CUSTOMER[R]: this group is equivalent to DEVICE_MANAGER[R] but gives larger access to billing rights information. You get more rights than with the DEVICE_MANAGER profiles, like for reporting and contract events.

– DEVICE_MANAGER[W]: This group extends the DEVICE_MANAGER[R] with all the needed rights to Create, Update and Delete any elements. It allows access to the PAC information and the geoloc payload but it also filter the informations about (SNR, frequencies, out-of-band, repeat). Basically we can consider this account as the standard admin right.

– CUSTOMER[W]: this group add to the previous one the rights to create contract events and restart Off-Contract devices. on the billing parts. It also gives the equivalent of DEVICE_MANAGER[W] for others (appart for suspend/resume device with token)

– DEVICE[R]: This group is really near the DEVICE_MANAGER[R] group the main differences are about the billing & user and API details & communications information this group can’t access. On the other hands this group gives access to more details on the SNR, frequencies, out-of-band, repeat informations.

– LIMITED_ADMIN: This group is not really an administration group. It is similar to DEVICE_MANAGER[W] with limited rights. It has no billing access, has only READ access on Devices but WRITE access on DeviceType, Groups and Users.

– ONLINE_HELP: This group has basically no rights more than being able to connect and access to the news & documentations.

– BILLING: This is more a Sigfox Internal profile, basically extending CUSTOMER[R] (see below) with extended billing rights.

As you can see these groups are not really granular, they are proposing default profiles decided by SigFox. Personally my opinion is they are too large and you can’t really decide what you want to share. For API rights, basically you need to create DeviceType from the backend, as adding devices and access the messages. But you can decide to not share your Billing informations and User informations. This type of profile does not exists and you have to share everything.

The second type of groups are more interesting as the granularity is really lower, so as you can set different group for a user you can mix them to compose the rights you want to share. The problem in my point of view is these groups are really limited ( or I do not have all attached to my account ?!? )

• Fine grained rights

– DEVICE_MESSAGE[R]: this group could be classified in the previous list but as it gives reduced rights on the DEVICE group only I add it here. These rights basically gives the message information access with limited details only.

– BILLING_API: This is a kind of minimal rights to access the contract informations in readonly.

– OPT_API_CREATION: allows to create API users

– OPT_DEVICETYPE_ORDER[W]: allows to display/create/update/delete deviceType and disengage sequence numbers.

– OPT_DEVICETYPE_READ: only allows to display devicetype informations.

– OPT_INTEGRATOR: allows to access the message advanced informations (repeat, out-of-band, rssi, Snr, frequencies) and delete messages.

– OPT_NOC_ENHANCED: allows to manage groups & Api access (Read and Write) but do not allows to create, modify, delete groups.

– OPT_SERVICE_MAP and PUBLIC_SERVICE_MAP: basically allows to access the network coverage informations.

The details of the rights for each groups is detailed in the following excel file containing the matrix rights/groups for Sigfox backend & API (Sigfox Matrix Rights for Backend and API).

To conclude, I hope the right management will be enhanced in the future. When taking a look to the matrix of rights, everything is in place for fine-grain-right management. In practice the group organization needs improvement to be configured correctly according to the needs of each backend. The objective is to be able to give the needed rights to a IoT platform but not making it “open-bar”. The main group definition mostly made for web access right management but now, more and more the need will be for managing the API access rights. This is requiring finest right management like we have in the second list, a good exemple of what’s wrong are the group CUSTOMER vs DEVICE_MANAGER they have large common parts, small differences sounding like a bug more than a choice due to right replication over the releases. A better implementation for this would have been to put in CUSTOMER only the part concerning the billing specificity in something like OPT_BILLING_EXTENDED group and an equivalent of CUSTOMER would have been DEVICE_MANAGER + OPT_BILLING_EXTENDED.

Basically, what we need is a larger set of OPT_xxx groups, having DEVICE_MANAGER split into multiple sub groups to be able to select some part as read, some other as readwrite, close access to some other. Hope to be hear.

Actually it seems you can ask support for creating specific profiles, just for you, if you have specific needs. I don’t know how they are managed over the releases. That’s not ideal for third party platform users. Apparently the API v2 could simplify this.