Optionaloptions: 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 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
@backstage/catalog-model#EntityRef. For other plugins, this can be
any serialized format. This is used to construct the
createPermissionIntegrationRouter, a function to add an authorization route
to your backend plugin. This function will be called by the
permission-backend when authorization conditions relating to this plugin
need to be evaluated.
use PermissionRegistryService instead, see the migration section in the service docs for more details.
Create an express Router which provides an authorization route to allow integration between the permission backend and other Backstage backend plugins. Plugin owners that wish to support conditional authorization for their resources should add the router created by this function to their express app inside their
createRouterimplementation.In case the
permissionsoption is provided, the router also provides a route that exposes permissions and routes of a plugin.In case resources is provided, the routes can handle permissions for multiple resource types.