🐛 Bug Report: Catalog Docs - Undefined User in Permission

[Nereis]

📜 Description

When trying to access the documentation after setting up the alpha catalog permission as below, the page load for ever and we can see in the permissions that the user, for this specific request only (coming from techdoc?), is not defined in the request context. This lead to a permissions rejection which is also not properly handled in the frontend (load for ever).

👍 Expected behavior

When opening the documentation from the catalog context view, the user should be pass to the permission layer or it should query another permission than "catalog.entity.read" in order to setup a specific exception rule.

Screenshot below with an hardcoded ALLOW permission

👎 Actual Behavior with Screenshots

The user is undefined most likely from the techdoc request leading the permission evaluation to a deny on the catalog.read request. Full log below when clicking on "DOCS" tab from the catalog page of the resource.

[1] 2023-08-14T08:43:44.502Z permission verbose Permission Request: Target: {"permission":{"type":"resource","name":"catalog.entity.delete","attributes":{"action":"delete"},"resourceType":"catalog-entity"}} User: user:default/my_user_company.ch type=plugin
[1] 2023-08-14T08:43:44.653Z permission verbose Permission Request: Target: {"permission":{"type":"resource","name":"catalog.entity.read","attributes":{"action":"read"},"resourceType":"catalog-entity"}} User: user:default/my_user_company.ch type=plugin
[1] 2023-08-14T08:43:44.673Z permission verbose Permission Request: Target: {"permission":{"type":"resource","name":"catalog.entity.read","attributes":{"action":"read"},"resourceType":"catalog-entity"}} User: user:default/my_user_company.ch type=plugin
[1] 2023-08-14T08:43:44.692Z permission verbose Permission Request: Target: {"permission":{"type":"resource","name":"catalog.entity.read","attributes":{"action":"read"},"resourceType":"catalog-entity"}} User: user:default/my_user_company.ch type=plugin
[1] 2023-08-14T08:43:44.723Z backstage info ::ffff:127.0.0.1 - - [14/Aug/2023:08:43:44 +0000] "POST /api/catalog/.well-known/backstage/permissions/apply-conditions HTTP/1.1" 200 74 "-" "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)" type=incomingRequest
[1] 2023-08-14T08:43:44.733Z backstage info ::ffff:127.0.0.1 - - [14/Aug/2023:08:43:44 +0000] "POST /api/permission/authorize HTTP/1.1" 200 - "-" "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)" type=incomingRequest
[1] 2023-08-14T08:43:44.742Z backstage info ::ffff:127.0.0.1 - - [14/Aug/2023:08:43:44 +0000] "POST /api/permission/authorize HTTP/1.1" 200 - "-" "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)" type=incomingRequest
[1] 2023-08-14T08:43:44.773Z backstage info ::1 - - [14/Aug/2023:08:43:44 +0000] "POST /api/permission/authorize HTTP/1.1" 200 74 "http://localhost:3000/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36 Edg/115.0.1901.203" type=incomingRequest
[1] 2023-08-14T08:43:44.803Z backstage info ::ffff:127.0.0.1 - - [14/Aug/2023:08:43:44 +0000] "POST /api/permission/authorize HTTP/1.1" 200 - "-" "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)" type=incomingRequest
[1] 2023-08-14T08:43:44.822Z permission verbose Permission Request: Target: {"permission":{"type":"resource","name":"catalog.entity.read","attributes":{"action":"read"},"resourceType":"catalog-entity"}} User: user:default/my_user_company.ch type=plugin
[1] 2023-08-14T08:43:44.982Z backstage info ::ffff:127.0.0.1 - - [14/Aug/2023:08:43:44 +0000] "POST /api/permission/authorize HTTP/1.1" 200 - "-" "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)" type=incomingRequest
[1] 2023-08-14T08:43:45.073Z backstage info ::ffff:127.0.0.1 - - [14/Aug/2023:08:43:45 +0000] "GET /api/catalog/entities/by-name/component/default/company-backstage HTTP/1.1" 200 - "-" "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)" type=incomingRequest
[1] 2023-08-14T08:43:45.083Z backstage info ::ffff:127.0.0.1 - - [14/Aug/2023:08:43:45 +0000] "GET /api/catalog/entities/by-name/component/default/company-backstage HTTP/1.1" 200 - "-" "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)" type=incomingRequest
[1] 2023-08-14T08:43:45.123Z backstage info ::ffff:127.0.0.1 - - [14/Aug/2023:08:43:45 +0000] "GET /api/catalog/entities/by-name/component/default/company-backstage HTTP/1.1" 200 - "-" "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)" type=incomingRequest
[1] 2023-08-14T08:43:45.142Z backstage info ::ffff:127.0.0.1 - - [14/Aug/2023:08:43:45 +0000] "GET /api/catalog/entities/by-name/component/default/company-backstage HTTP/1.1" 200 - "-" "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)" type=incomingRequest
[1] 2023-08-14T08:43:45.163Z backstage info ::1 - - [14/Aug/2023:08:43:45 +0000] "GET /api/techdocs/static/docs/default/component/company-backstage/index.html HTTP/1.1" 304 - "http://localhost:3000/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36 Edg/115.0.1901.203" type=incomingRequest
[1] 2023-08-14T08:43:45.183Z backstage info ::1 - - [14/Aug/2023:08:43:45 +0000] "GET /api/techdocs/metadata/entity/default/component/company-backstage HTTP/1.1" 304 - "http://localhost:3000/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36 Edg/115.0.1901.203" type=incomingRequest
[1] 2023-08-14T08:43:45.363Z backstage info ::1 - - [14/Aug/2023:08:43:45 +0000] "GET /api/techdocs/metadata/techdocs/default/component/company-backstage HTTP/1.1" 304 - "http://localhost:3000/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36 Edg/115.0.1901.203" type=incomingRequest

##### Permission receive user undefined and will DENY #####
[1] 2023-08-14T08:43:45.492Z permission verbose Permission Request: Target: {"permission":{"type":"resource","name":"catalog.entity.read","attributes":{"action":"read"},"resourceType":"catalog-entity"}} User: undefined type=plugin

##### 404 on the following request #####
[1] 2023-08-14T08:43:45.493Z backstage info ::ffff:127.0.0.1 - - [14/Aug/2023:08:43:45 +0000] "POST /api/permission/authorize HTTP/1.1" 200 426 "-" "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)" type=incomingRequest
[1] 2023-08-14T08:43:45.622Z backstage info ::ffff:127.0.0.1 - - [14/Aug/2023:08:43:45 +0000] "GET /api/catalog/entities/by-name/component/default/company-backstage HTTP/1.1" 404 564 "-" "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)" type=incomingRequest
[1] 2023-08-14T08:43:45.643Z backstage info ::1 - - [14/Aug/2023:08:43:45 +0000] "GET /api/techdocs/static/docs/default/component/company-backstage/assets/stylesheets/main.50e68009.min.css HTTP/1.1" 404 525 "http://localhost:3000/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36 Edg/115.0.1901.203" type=incomingRequest

##### Techdocs return  #####
[1] 2023-08-14T08:43:45.663Z backstage info ::1 - - [14/Aug/2023:08:43:45 +0000] "GET /api/techdocs/sync/default/component/company-backstage HTTP/1.1" 200 - "http://localhost:3000/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36 Edg/115.0.1901.203" type=incomingRequest

👟 Reproduction steps

Add the permission to limit the access to catalog.entity.read. Our codde snippet based on documentation below

class CompanyPermissionPolicy implements PermissionPolicy {
  constructor(private readonly logger: Logger) {}

  async handle(request: PolicyQuery, user?: BackstageIdentityResponse): Promise<PolicyDecision> {
    this.logger.verbose(
      `Permission Request: Target: ${JSON.stringify(request)} User: ${user?.identity.userEntityRef}`,
    );

    if (isResourcePermission(request.permission, RESOURCE_TYPE_CATALOG_ENTITY))
      return this.handleCatalogEntity(request.permission, user);

    this.logger.warn(`Request Denied: Target:${request.permission.name} User:${user?.identity.userEntityRef}`);
    return this.deny();
  }
  
   /** Allow user to manage their group resource
   *    and too see public documentation
   */
  async handleCatalogEntity(
    permission: ResourcePermission<'catalog-entity'>,
    user?: BackstageIdentityResponse,
  ): Promise<PolicyDecision> {
    // All CRUD Permissions
    const ownerCond: PermissionCondition<'catalog-entity', PermissionRuleParams> = catalogConditions.isEntityOwner({
      claims: user?.identity.ownershipEntityRefs ?? [],
    });

    const condListOr: NonEmptyArray<PermissionCondition<'catalog-entity', PermissionRuleParams>> = [ownerCond];

    if (isPermission(permission, catalogEntityReadPermission)) {
      const kindUserCond: PermissionCondition<'catalog-entity', PermissionRuleParams> = catalogConditions.isEntityKind({
        kinds: ['User'],
      });
      condListOr.push(kindUserCond);

      const docCond = catalogConditions.hasSpec({
        key: 'type',
        value: 'documentation',
      });
      condListOr.push(docCond);
    }

    return createCatalogConditionalDecision(permission, {
      anyOf: condListOr,
    });
  }
  ...
}

📃 Provide the context for the Bug.

We are trying to add the permission on the catalog using the alpha permission from the official documentation

🖥️ Your Environment

Backstage 1.16.0
Mermaid 9.4.3
@backstage/plugin-techdocs-react@npm:1.1.8
backstage-plugin-techdocs-addon-mermaid@npm:0.8.0

👀 Have you spent some time to check if this bug has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

Are you willing to submit PR?

No, I don't have time to work on this right now

[benjdlambert]

@vinzscam anything stand out to you here?

[vinzscam]

Hi @Nereis,
have you added cookie based authentication? https://backstage.io/docs/permissions/getting-started#optionally-add-cookie-based-authentication

[Nereis]

Yes we do, similar to the documentation you provided.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Joonpark13]

I've gone and reproduced the policy that you provided and in my setup it seems to work as intended, so I think it's safe to say it's not the policy itself. I'm guessing it's probably whatever is upstream that is providing the user to the policy. Is there anything notable with your identity provider setup?

[zjpersc]

I am experiencing the exact same situation here. When I try to access techdocs for an entity, I see in the logs:

permission info Policy check for undefined for permission catalog.entity.read type=plugin
permission info undefined is DENY for permission catalog.entity.read and action read type=plugin

@Joonpark13 - Nothing special about our provider setup. We're using the default Microsoft resolver/provider.

@Nereis - Did you resolve your issue? If so, do you remember what you did?

[Nereis]

No, I don't. i remove the faulty permission for now.

[zjpersc]

So I will also add that after migrating to the new backend architecture/configuration, the permissions are working for me. I don't know if I had something misconfigured in the API authentication that I didn't duplicate when I set it up for the new architecture, but it works.

[Rugvip]

Looks like neither of you are facing this issue anymore, closing

[Nereis]

@Rugvip Removing all the permissions is not really a solution...

[Rugvip]

@Nereis alright, reopened!

[benjdlambert]

@Nereis can you verify that the cookie is present in the requests to techdocs? It looks like there's some issue with your cookie authentication and it's not being applied or sent through which is possibly why this only fails in techdocs.

[Nereis]

@benjdlambert We are starting the migrate to the new backends. I propose we wait and see it fixes the issue as raised by zjpersc

[zjpersc]

I still have both legacy and new backends in parallel. I was doing some testing and I'm seeing that there is notable difference in token size for the new backend (Techdocs works) and the legacy backend (Techdocs spins - undefined error in backend). I'm 99.9% positive that it has to do with some difference between the authMiddlewareFactory (used in new backend) and authMiddleware (used on legacy) and how the cookie is being set.

https://github.com/backstage/backstage/blob/master/contrib/docs/tutorials/authenticate-api-requests.md

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[benjdlambert]

Is this still an issue in the latest 1.26 release? We've shipped a lot fixes for auth and techdocs + permissions.

[Nereis]

We started migrating, we'll reactivate the permissions and check

[gaelgoth]

I'm a colleague of @Nereis and we are running Backstage v1.27.2. We migrated all our plugins to the new backend system and removed the workaround. It fixed the issue, so far, we haven't noticed any issues with the policy or undefined user token error.

[vinzscam]

Closing the issue, thank you for confirming @gaelgoth 🙏