Release version
APIOps Toolkit for Azure APIM v7.0.2
Describe the bug
All 4 workspace ILinkResource types store a fully-qualified ARM resource ID in their extracted JSON that is specific to the source environment. When the publisher sends these DTOs verbatim to a different target APIM instance, ARM's linked-scope authorization check fails because the embedded path still references the source service.
The affected files and properties are:
| File |
Property |
REST endpoint |
productGroupInformation.json |
groupId |
workspaces/{ws}/products/{p}/groupLinks |
productApiInformation.json |
apiId |
workspaces/{ws}/products/{p}/apiLinks |
tagApiInformation.json |
apiId |
workspaces/{ws}/tags/{t}/apiLinks |
tagProductInformation.json |
productId |
workspaces/{ws}/tags/{t}/productLinks |
Example extracted productGroupInformation.json:
{
"name": "6a02ee928bedff2038e046fb",
"properties": {
"groupId": "/subscriptions/<SOURCE-SUB>/resourceGroups/<SOURCE-RG>/providers/Microsoft.ApiManagement/service/<SOURCE-APIM>/groups/administrators"
}
}
The publisher has no compensating logic to rewrite the ARM prefix to the target environment before the PUT.
Expected behavior
The publisher rewrites the absolute ARM prefix in the link body property to the target environment before the PUT.
Actual behavior
Publisher fails with HTTP 403:
LinkedAuthorizationFailed: The client has permission to perform
'workspaces/products/groupLinks/write' on the target scope, but does not have
permission to perform 'service/groups/write' on the linked scope
'.../service/<SOURCE-APIM>/groups/administrators'
or the linked scope is invalid.
Reproduction Steps
- Have two APIM instances with workspaces. Ensure the workspace link does not yet exist in the target.
- In the source, link a workspace product to a group (or API), or a workspace tag to an API or product.
- Run the extractor against the source — the extracted JSON contains an absolute ARM
groupId/apiId/productId referencing the source environment.
- Run the publisher against the target — it fails with
LinkedAuthorizationFailed 403.
Release version
APIOps Toolkit for Azure APIM v7.0.2
Describe the bug
All 4 workspace ILinkResource types store a fully-qualified ARM resource ID in their extracted JSON that is specific to the source environment. When the publisher sends these DTOs verbatim to a different target APIM instance, ARM's linked-scope authorization check fails because the embedded path still references the source service.
The affected files and properties are:
productGroupInformation.jsongroupIdworkspaces/{ws}/products/{p}/groupLinksproductApiInformation.jsonapiIdworkspaces/{ws}/products/{p}/apiLinkstagApiInformation.jsonapiIdworkspaces/{ws}/tags/{t}/apiLinkstagProductInformation.jsonproductIdworkspaces/{ws}/tags/{t}/productLinksExample extracted
productGroupInformation.json:{ "name": "6a02ee928bedff2038e046fb", "properties": { "groupId": "/subscriptions/<SOURCE-SUB>/resourceGroups/<SOURCE-RG>/providers/Microsoft.ApiManagement/service/<SOURCE-APIM>/groups/administrators" } }The publisher has no compensating logic to rewrite the ARM prefix to the target environment before the PUT.
Expected behavior
The publisher rewrites the absolute ARM prefix in the link body property to the target environment before the PUT.
Actual behavior
Publisher fails with HTTP 403:
Reproduction Steps
groupId/apiId/productIdreferencing the source environment.LinkedAuthorizationFailed403.