Problem / limitation
Target Filter Query CRUD operations are currently gated behind the generic TARGET permissions (CREATE_TARGET, READ_TARGET, UPDATE_TARGET, DELETE_TARGET). This makes it impossible to grant a user the ability to register devices without also granting them the ability to create, modify, or delete target filters.
Example: A "factory" user whose sole responsibility is registering devices (targets) via POST /rest/v1/targets must be granted CREATE_TARGET — but this same permission also allows POST /rest/v1/targetfilters, which is an unrelated and potentially dangerous operation.
Expected Behavior
Target Filter Query operations should be protected by their own permission group, following the existing pattern:
CREATE_TARGET_FILTERREAD_TARGET_FILTERUPDATE_TARGET_FILTERDELETE_TARGET_FILTER
This is consistent with how other resource types are handled (e.g. CREATE_ROLLOUT, CREATE_DISTRIBUTION_SET, etc.).
Suggested Implementation
- Add constants to
SpPermission.java:
public static final String TARGET_FILTER = "TARGET_FILTER";
public static final String CREATE_TARGET_FILTER = CREATE_PREFIX + TARGET_FILTER;
public static final String READ_TARGET_FILTER = READ_PREFIX + TARGET_FILTER;
public static final String UPDATE_TARGET_FILTER = UPDATE_PREFIX + TARGET_FILTER;
public static final String DELETE_TARGET_FILTER = DELETE_PREFIX + TARGET_FILTER;
- Include the new group in
getAuthorities().
- Apply the new permissions in
MgmtTargetFilterQueryRestApi (or its resource implementation),
replacing the current TARGET permission checks.
- Update documentation (
docs/authorization.md).
Current Behavior (from API docs)
| Operation |
Required permission |
GET /targetfilters |
READ_TARGET |
POST /targetfilters |
CREATE_TARGET |
PUT /targetfilters/{id} |
UPDATE_TARGET |
DELETE /targetfilters/{id} |
DELETE_TARGET |
Use Case
We are defining a production provisioning workflow for devices that lack a TPM or Secure Element, and therefore cannot use mTLS for authentication out of the box.
The approach we have settled on is to inject a per-device security token immediately after the initial firmware flash, while the device is still on the production line. This operation is performed by a restricted "factory" user whose sole responsibility is registering devices and setting their security token (this will be partially automated).
To follow the principle of least privilege, this user should only be granted CREATE_TARGET + READ_TARGET. However, those same permissions currently also allow managing target filters, which drive auto-assignment rollouts — a completely unrelated and potentially destructive capability.
Introducing a dedicated TARGET_FILTER permission group would allow operators to precisely scope
factory accounts without exposing rollout automation controls.
Problem / limitation
Target Filter Query CRUD operations are currently gated behind the generic
TARGETpermissions (CREATE_TARGET,READ_TARGET,UPDATE_TARGET,DELETE_TARGET). This makes it impossible to grant a user the ability to register devices without also granting them the ability to create, modify, or delete target filters.Example: A "factory" user whose sole responsibility is registering devices (targets) via
POST /rest/v1/targetsmust be grantedCREATE_TARGET— but this same permission also allowsPOST /rest/v1/targetfilters, which is an unrelated and potentially dangerous operation.Expected Behavior
Target Filter Query operations should be protected by their own permission group, following the existing pattern:
CREATE_TARGET_FILTERREAD_TARGET_FILTERUPDATE_TARGET_FILTERDELETE_TARGET_FILTERThis is consistent with how other resource types are handled (e.g.
CREATE_ROLLOUT,CREATE_DISTRIBUTION_SET, etc.).Suggested Implementation
SpPermission.java:getAuthorities().MgmtTargetFilterQueryRestApi(or its resource implementation),replacing the current
TARGETpermission checks.docs/authorization.md).Current Behavior (from API docs)
GET /targetfiltersREAD_TARGETPOST /targetfiltersCREATE_TARGETPUT /targetfilters/{id}UPDATE_TARGETDELETE /targetfilters/{id}DELETE_TARGETUse Case
We are defining a production provisioning workflow for devices that lack a TPM or Secure Element, and therefore cannot use mTLS for authentication out of the box.
The approach we have settled on is to inject a per-device security token immediately after the initial firmware flash, while the device is still on the production line. This operation is performed by a restricted "factory" user whose sole responsibility is registering devices and setting their security token (this will be partially automated).
To follow the principle of least privilege, this user should only be granted
CREATE_TARGET+READ_TARGET. However, those same permissions currently also allow managing target filters, which drive auto-assignment rollouts — a completely unrelated and potentially destructive capability.Introducing a dedicated
TARGET_FILTERpermission group would allow operators to precisely scopefactory accounts without exposing rollout automation controls.