Bosch IoT Rollouts can be accessed in several ways:

• Management UI by users
• Management API by 3rd-party applications
• Direct Device Integration (DDI) API by IoT devices
• Artifact downloads by targets
• Device Management Federation (DMF) API by 3rd party applications through AMQP
• Service Integration Event (SIE) API by 3rd-party applications through AMQP

Table of contents:

Management UI

If you are a new user, see how to book your Rollouts subscription in the Ordering Process.

If you already have an account, see how to access the service in the Accessing Bosch IoT Rollouts

Management API

Option 1: Bosch IoT Rollouts Cloud User

• Rollouts Basic Auth as provided after booking
  User: "TENANT\USERNAME"
  Password: "PASSWORD"

Option 2: Authenticate with OAuth2

3rd-party applications that use or connect to Bosch IoT Rollouts can also authenticate via OAuth2.

Two authorization grant types are currently supported: Authorization Code Grant and Client Credentials Grant.

Please note that the tenant is always required in the URL, regardless of the grant type.

Authorization Code Grant

An access token issued by SingleKey ID or Bosch IdP is accepted.

Client Credentials Grant

An access token issued by an OAuth2 client of Rollouts IdP is accepted. For more details on managing clients, see Rollouts OAuth2 clients.

Direct Device Integration API

Bosch IoT Rollouts supports multiple ways to authenticate a target against the server. The different authentication modes can be enabled or disabled individually within Bosch IoT Rollouts.

Certificate-based authentication

Bosch IoT Rollouts allows the authentication based on X.509 certificates. This is the preferred authentication mode. In this case, the target (device) needs to send a complete (self-contained) certificate chain along with the request, which is then validated by a trusted reverse proxy. The certificate chain can contain multiple certificates, e.g., a target-specific client certificate, an intermediate certificate, and a root certificate.

After terminating the TLS connection, the proxy validates the certificate chain and, provided the chain is valid, retrieves the SHA-256 fingerprint of each certificate. The fingerprints and the client certificate common name are then forwarded to the DDI server via special HTTP headers. Note that the client certificate common name must match the ID of the target being addressed. To establish trust with the client certificate of the target, the SHA-256 fingerprints of the root and intermediate certificates are then matched against the SHA-256 certificate fingerprints stored in the system configuration of your account.

If you want to use this authentication mode, you need to enable it for your account in the Configuration UI feature:

1. Enter edit mode via the Edit icon on the top right of the view.
   
2. Enable the Allow targets to authenticate via a certificate authenticated by a reverse proxy.
3.  Аdd the SHA-256 certificate fingerprint of your intermediate or root CA.

Note: You can enter multiple certificate fingerprints, separated by a semicolon. Bosch IoT Rollouts verifies that at least one of the provided fingerprints matches an incoming issuer hash header. This is useful for certificate migration.

Find an example of this authentication mode, including step-by-step instructions using OpenSSL and cURL, in the Set up client certificate-based authentication for devices.

Target security token authentication

A 32-character alphanumeric security token is generated for each target created in Bosch IoT Rollouts. This token can be used to authenticate the target at Bosch IoT Rollouts via the HTTP Authorization header with the custom scheme TargetToken.

The target security token is provided in the Device Management Federation (DMF) API as part of the update message to allow DMF clients to leverage the feature, or it can be manually retrieved per target by the Management API or in the Management UI  in the target details.

This feature must be activated for your account in the Configuration UI:

Gateway security token authentication

Often, the targets are connected through a gateway that manages the targets directly and, as a result, are indirectly connected to the Bosch IoT Rollouts update server.

To authenticate this gateway and allow it to manage all target instances under its tenant, use a GatewayToken in the HTTP Authorization header with the custom scheme GatewayToken. This is, of course, also handy during development or for testing purposes. However, we generally recommend using this token with great care, as it allows one to act “in the name of” any device.

This feature must be activated for your account in the Configuration UI:

1. Enable the Allow a gateway to authenticate and manage multiple targets through a gateway security token configuration.
2. Click Show, then copy the token using the icon to its right.

Artifact download authentication

Download artifacts

In Bosch IoT Rollouts, artifact downloads are handled via signed URLs. This means no device authentication (DDI credentials) is required when downloading an artifact. However, to get the download URL by deployment base, the device has to be authenticated. Furthermore, the received download URL is valid for 1 month. This means that devices might have to re-call the deployment base if access is denied. Artifacts are delivered through a worldwide Content Delivery Network (CDN) to provide high availability and performance for downloads.

Device Management Federation (DMF) API and Service Integration Event (SIE) API

Authentication is provided by the Bosch IoT Rollouts service broker interface, with a separate RabbitMQ vhost and user credentials for each service binding.