Authorization is handled separately for Direct Device Integration (DDI) API and Device Management Federation (DMF) API (where successful authentication includes full authorization) and Management API and UI which is based on permissions.


An authenticated target is permitted to:

  • retrieve commands from the server.
  • provide feedback to the server.
  • download artifacts that are assigned to it.

Anonymous download

A target might be permitted to download artifacts without authentication (if enabled, see above).

Management API and UI

The Bosch IoT Rollouts permissions grant access to different repository functionality and data. The permissions are identical between the two authentication options described above, i.e. either combined with a separately purchased Bosch IoT Permissions instance or the Rollouts Cloud User.

By default in the Cloud User user scenario a root user will be generated including username and password. This root user is granted with all permissions. Additional Bosch account registered users can be added by user management view in the Management UI. Keep in mind that Bosch account works as of now only for Management UI. For the Management API the root user has to be used for the time being (see above).

Delivered permissions

    • Target entities including metadata (that includes also the installed and assigned distribution sets)
    • Target tags
    • Target actions
    • Target registration rules
    • Bulk operations
    • Target filters
    • Distribution sets
    • Software Modules
    • Artifacts
    • DS tags
    • Permission to read the target security token. The security token is security concerned and should be protected.
    • Permission to download artifacts of a software module (Note: READ_REPOSITORY allows only to read the metadata).
    • Permission to administrate the tenant settings.
    • Permission to provision targets through rollouts (not included in starter plan).
    • Access to User Management view
    • Manage the permissions of users via UI and API
    • Access to Role Management view
    • Manage the permissions of roles via UI and API
    • Replaces User Management if an own identity provider is configured

Permission matrix for example uses cases that need more than one permission

Use Case Needed permissions
Search targets by installed or assigned distribution set READ_TARGET, READ_REPOSITORY
Assign DS to target through a Rollout, i.e. Rollout creation and start READ_REPOSITORY, CREATE_ROLLOUT, HANDLE_ROLLOUT
Read Rollout status including its deployment groups READ_ROLLOUT
Checks targets inside Rollout deployment group READ_TARGET, READ_ROLLOUT

Optional Bosch IoT Permissions (included default roles)

Deployment admin

The deployment administrators job is to manage the targets itself and trigger actions on them.

Contains the permissions:

  • READ_REPOSITORY to find out what is deployed on the targets

Repository admin

The repository administrator manages the software repository itself including information concerning the deployment status of the repository artifacts.

Contains the permissions:

  • READ_/UPDATE_/CREATE_/DELETE_REPOSITORY to manage the repository
  • READ_TARGETS in order to find out where the repository content is applied
  • DOWNLOAD_REPOSITORY_ARTIFACT to download artifacts

Rollout Admin

The rollout administrator manages the rollouts or campaigns for large scale update operations.

Contains the permissions:

  • READ_/UPDATE_/CREATE_/DELETE_ROLLOUT to manage the rollouts
  • HANDLE_ROLLOUT to start or pause a rollout
  • READ_REPOSITORY to define the software that is applied through the rollout
  • READ_TARGET to see target filters for rollout definition and targets in the rollout groups

Support agent

The support agent can look into targets and repository in order to investigate support cases.

Contains the permissions:

  • READ_REPOSITORY, READ_TARGET for situation overview.

Tenant administrator

The tenant administrator can configure tenant specific settings.


Device Management Federation API

The RabbitMQ vhost and user is provided with the necessary permissions to send messages to Rollouts through the exchange and receive messages from it through the specified queue. In addition, the permission exists for an application to create their own queues and exchanges and in combination with the reply to header tell Rollouts to send all messages into that setup.