Skip to content

[BUG] Publisher fails with LinkedAuthorizationFailed when deploying workspace link resources across environments #853

Closed

Description

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

  1. Have two APIM instances with workspaces. Ensure the workspace link does not yet exist in the target.
  2. In the source, link a workspace product to a group (or API), or a workspace tag to an API or product.
  3. Run the extractor against the source — the extracted JSON contains an absolute ARM groupId/apiId/productId referencing the source environment.
  4. Run the publisher against the target — it fails with LinkedAuthorizationFailed 403.

Activity

  1. github-actions commented on May 13, 2026

    @github-actions
      Thank you for opening this issue! Please be patient while we will look into it and get back to you as this is an open source project. In the meantime make sure you take a look at the [closed issues](https://github.com/Azure/apiops/issues?q=is%3Aissue+is%3Aclosed) in case your question has already been answered. Don't forget to provide any additional information if needed (e.g. scrubbed logs, detailed feature requests,etc.).
      Whenever it's feasible, please don't hesitate to send a Pull Request (PR) our way. We'd greatly appreciate it, and we'll gladly assess and incorporate your changes.
    
  2. guythetechie commented on May 20, 2026

    @guythetechie
    Contributor

    Michel V (@michelversluijs) - the publisher doesn't support rewriting APIM service names in links. It takes a JSON, applies any configuration overrides, and publishes the overridden JSON as-is. There are only two supported workarounds at the moment:

    • After extracting, manually update the service name in the extracted JSON.
    • Update the publisher's configuration override with the target service name.

    We try to extract relative IDs where possible in v7. Unfortunately, APIM doesn't support relative IDs for certain resources. We explicitly exclude them here:

    // Workspace product groups don't support relative IDs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions