Interface PermissionsRegistryService

Remarks

Rules should be created using corresponding create*PermissionRule functions exported by plugins, who in turn are created with makeCreatePermissionRule.

Rules can be added either directly by the plugin itself or through a plugin module.

Remarks

To make this concrete, we can use the Backstage software catalog as an example. The catalog has conditional rules around access to specific entities in the catalog. The type of resource is captured here as resourceType, a string identifier (catalog-entity in this example) that can be provided with permission definitions. This is merely a type to verify that conditions in an authorization policy are constructed correctly, not a reference to a specific resource.

The rules parameter is an array of @backstage/plugin-permission-node#PermissionRules that introduce conditional filtering logic for resources; for the catalog, these are things like isEntityOwner or hasAnnotation. Rules describe how to filter a list of resources, and the conditions returned allow these rules to be applied with specific parameters (such as 'group:default/team-a', or 'backstage.io/edit-url').

The getResources argument should load resources based on a reference identifier. For the catalog, this is an entity reference. For other plugins, this can be any serialized format. This is used to add a permissions registry API via the HTTP router service. This API will be called by the permission-backend when authorization conditions relating to this plugin need to be evaluated.

Remarks

Primarily intended for use with @backstage/plugin-permission-node#createConditionAuthorizer and @backstage/plugin-permission-node#createConditionTransformer.