Bosch IoT Device Management - will be discontinued by mid 2024

Create a policy entry for your backend application

Prerequisites

You are empowered to change the specific policy.

Goal

Given you need to provide a backend application permissions to the resources of a thing associated to the policy "your.namespace:policy-01".


The application itself should only have following permissions:

  • Read ALL entries.

  • Read and write attributes,

    • except writing the attributes/gsadapter


Request

Use the API docs of Bosch IoT Things

  • Authorize with a fresh Suite OAuth token.
    See Create a Suite Auth client

  • Policies resource:

    • PUT/policies/{policyId}/entries/{label}

    • Click Try it out

    • Set the policyId to your.namespace:policy-01

    • Set the label to "Dashboard"

    • Set the Request body

      {
      "subjects": {
      "iot-things:<your-things-solution-id>:my-dashboard":{
      "type": "iot-things-clientid"},
      "bosch:<your-bosch-id-optional-for-testing-via-http-api-docs>": {
      "type": "bosch-id"}
      },
      "resources": {
      "thing:/": {
      "grant": ["READ"],
      "revoke": []
      },
      "thing:/attributes": {
      "grant": [
      "READ",
      "WRITE"
      ],
      "revoke": []
      },
      "thing:/attributes/gsadapter": {
      "grant": ["READ"],
      "revoke": ["WRITE"]
      }
      }
      }

    • Execute

Test

Test with the Bosch ID.
If the user is not able to do what you need to restrict for the client, the resource part is ok, and you only need to delete the Bosch ID subject from this policy entry before going productive.


Do not lock yourself out from the ones who are able to edit the policy
As soon as the new policy does not allow the "subject" (in which context you would be able to work) to read and write the policy, you will have no way to "repair" it.
Call support for serious problems, or start from the scratch with a new policy which fits your requirements, then call support to help you attach potentially "lost" things to the new policy.

A policy will not warn you in case you try to delete it, but a thing still "depends" on it.

Nor will a change fail, in case you make a mistake in the subject's part.

Do not use the DEFAULT entry as a sandbox, but always create own small entries which you understand and you can deal with the impact.

Deleting small policy entries is a lot easier then deleting a complete policy.


Your complete policy would look similar to the following example:

{
"policyId": "your.namespace:policy-01",
"entries": {
// "DEFAULT": {},
// "DEVICE": {},
// "DEVICE-MANAGEMENT": {},
"Dashboard": {
"subjects": {
"iot-things:<your-things-solution-id>:my-dashboard": {
"type": "iot-things-clientid"
},
"bosch:<your-bosch-id-optional-for-testing-via-http-api-docs>": {
"type": "bosch-id"
}
},
"resources": {
"thing:/attributes": {
"grant": [
"READ",
"WRITE"
],
"revoke": []
},
"thing:/": {
"grant": [
"READ"
],
"revoke": []
},
"thing:/attributes/gsadapter": {
"grant": [
"READ"
],
"revoke": [
"WRITE"
]
}
}
}
}
}


Further reading

The basic concept and all types of subject and resources are documented at Digital twins > Policy of a thing.