After speaking with Anders about integrating OPA with Backstage, a possible improvement would be to make the package name more dynamic.

I also had an idea while traveling that we could make the config accept an array of "configs" something like:

opa-client:
  opa:
    baseUrl: 'http://localhost:8181/v1/data/opa/main'
    policies:
      plugin: entity-checker
        package: 'entitymeta'
      plugin: catalog-entity
        package: 'catalog_policy'
      plugin: some-other-plugin
        package: 'some-other-package'

We could then do something here

Which would make it more dynamic 🤔 💭

Another option is to look at making a main package and then extending it as advised here

I'd like to update the README.md in the root of the repository to explain a bit what this repo is about.

Is your feature request related to a problem? Please describe.
The README's for each plugin need updating:

• Using legacy backend
• Using new backend
• Installation instructions fully correct?

Describe the solution you'd like
A clear and concise description of what is required when installing the plugins on any backend system.

Describe alternatives you've considered
None

Additional context
The docs are not bad, they just need updating and refining a bit.

Is your feature request related to a problem? Please describe.
Not frustrating, but we should look at moving to the new Backend system for Backend plugins in Backstage.

Describe the solution you'd like
Something like this -> https://backstage.io/docs/plugins/new-backend-system/

Describe alternatives you've considered
We can leave it for now, and worry about this later.

Additional context
Have to make sure it works for both legacy and new backend system (this includes the permissions framework from backstage itself as well) but this should not be too much of an issue.

This part of the docs is no longer correct:

opa-client:
  opa:
    baseUrl: http://your-opa-server-url
    policies:
      catalog:
        package: your-catalog-package

It should actually be:

opa-client:
  opa:
    baseUrl: 'http://localhost:8181'
    policies:
      entityChecker: --> Entity checker plugin
        package: 'entitymeta'
      catalogPermission: --> Permission wrapper plugin
        package: 'catalog_policy'

Needs updating here: https://github.com/Parsifal-M/brewed-backstage/blob/main/plugins/opa-backend/README.md and could also be updated here: https://github.com/Parsifal-M/brewed-backstage/blob/main/plugins/opa-permissions-wrapper/README.md

Or atleast the back-end plugin should be the source of truth for it and we can just reference to that file in the wrapper plugin.

Would be nice to have some more example policies that people can get some inspiration from.

Or I wonder if we could even template some.

Part of #31

Possible Steps ⚠️ braindump ⚠️

1. OPA Returns the Conditional Response
2. Template it with JSON or Yaml
3. In the App-Config
4. Has to be modular and not require recompiling the app to work!

Is your feature request related to a problem? Please describe.
Would be nice to have a front-end for the OPA plugins, especially the Permissions Wrapper, this way you could post new policies to the OPA API.

Describe the solution you'd like
A front-end plugin that users can use to upload policies to OPA which would be running alongside Backstage

Describe alternatives you've considered
There are alternative ways to upload policies to OPA via bundles or other community ways, so this would be nice to have.

Additional context
I'm not sure how much auditing we want to look at enabling here, if a policy is modified you probably want to know by whom and when.

Is your feature request related to a problem? Please describe.
I'm still not too happy with how the error logging works, I would like some more clear precise error logs for when something goes wrong.

Describe the solution you'd like
Better logging, especially in the OPA Backend and Permissions Wrapper

Describe alternatives you've considered
None

Additional context
One thing especially annoying is that if we specify a policy/package but its not present on the OPA server it will just return a JSON error, I'd like this to be changed to advise in some form that the specified package does not exist for example.

I don't think we use "node-fetch": "^2.6.7", so this should be removed as a dependency.

https://github.com/Parsifal-M/brewed-backstage/blob/1c83ecd0a812777589e31d18c56e1797de2f2852/plugins/opa-backend/package.json#L42

This is to keep track of ideas and solutions for using OPA as a permission framework.

Is your feature request related to a problem? Please describe.
I always forget how this thing works, especially if I take some time off. Would be nice to have some pictures for reference.

Describe the solution you'd like
Something in MermaidJS or Draw.io to better understand how things work.

Describe alternatives you've considered
Add more text to the readme, but I think pictures make it easier to digest.

Additional context
N/A

Is your feature request related to a problem? Please describe.

It would be great to list the available conditional rules from the catalog plugin from the Backstage repository.

Describe the solution you'd like

We can add them to a readme somewhere close to policies to help people make policies using the rules.

Describe alternatives you've considered

We just don't do it, but that wouldn't be very nice now would it? 😐

Additional context

I don't think there is any specific docs on the available rules, we'll have to go diving into the code 🤿

Is the NPM OPA WASM worth trying?

Based on feedback, it would be nice to understand what the policies are supposed to achieve.

Maybe not specifically related to this repo but I want to write down we should have a frontend for the OPA plugin.

While the policy model provided by the Backstage permissions framework works great, it would also be interesting to explore models where OPA has more say in the decisions being made. More specifically, I'd like to see an implementation where OPA doesn't merely pass conditional queries back to the plugins, but overrides the decision-making entirely, and side-steps the plugin's ownership of permissions in favor of the decoupled, externalized model that's more commonly seen in OPA integrations. Both approaches have their pros and cons, of course, and we'll want to document how these differ as part of this.

We got some helpful suggestions on how to accomplish this in the Backstage Discord (thanks @vinzscam!), like overriding the PermissionEvaluator interface with our own client implementation, so let's start there.

Is your feature request related to a problem? Please describe.
Remove dependency on OPA Backend for the OPA Permission Wrapper.

Describe the solution you'd like
Its not strictly nesecessary for the OPA Permission Wrapper to use the OPA Backend, we could make the wrapper talk directly to OPA instead.

Describe alternatives you've considered
We continue to use the OPA Backend, requiring two plugins in order for it to work.

Additional context
N/A

Currently, we only support Catalog based decisions, we need to be able to also support Scaffolder decisions.

As seen here: https://backstage.io/docs/features/software-templates/authorizing-parameters-steps-and-actions

Is your feature request related to a problem? Please describe.
The Architecture Documents need sprucing up a bit as they are slightly out of date.

Describe the solution you'd like
What it looks like on OLD Backend and NEW Backend.

Describe alternatives you've considered
None

Additional context
Just needs updating.

It would be nice to have a front-end component for the OPA plugin, it could start off as something simple to just view the current policies on the OPA server.

Then we can modify it later on to also maybe be able to send new policies/update policies.

Is your feature request related to a problem? Please describe.
The OPA Entity Checker plugin needs to be updated to also support the entrypoints (like the OPA permission wrapper)

Describe the solution you'd like
Same as the OPA wrapper, so we can use entrypoints instead of evaluating the whole policy

Describe alternatives you've considered
N/A

Additional context
N/A

It wasn't clear from the docs what the name of the rule which was to be evaluated should be, as only the package was requested in configuration. The name shouldn't matter however, and I think it would be preferable if the user could set an entrypoint instead of a package. Entrypoints would be either a package or a package/rule combination and using any level of nesting, like policy, policy/backstage/permissions or policy/backstage/permissions/decision.

Update the readme, or add a section/another readme for spinning up this backstage instance.

Can help people trying to contribute to certain plugins as not all of them can be spun up in isolation.

This way we could technically edit policies in the UI. 😍

This is wrong:

import { createRouter } from '@backstage/plugin-permission-backend';
import { Router } from 'express-serve-static-core';
import { PluginEnvironment } from '../types';
import {
  OpaClient,
  PermissionsHandler,
} from '../../../../plugins/opa-permissions-wrapper/src';

Should be this:

import { createRouter } from '@backstage/plugin-permission-backend';
import { Router } from 'express-serve-static-core';
import { PluginEnvironment } from '../types';
import { OpaClient, PermissionsHandler } from '@parsifal-m/opa-permissions-wrapper'

Needs updating in the documentation for the back-end plugin here: https://github.com/Parsifal-M/brewed-backstage/blob/main/plugins/opa-permissions-wrapper/README.md

I would like to separate the plugins into their own repos.

Description
The docs need updating as we do not use "decision" necessarily anymore, just the result

Additional context
Should be updated before next release.

Files are here: https://github.com/Parsifal-M/backstage-opa-plugins/blob/main/docs/example-inputs-outputs.md

For any given action I seem to get all of this printed at info level:

[1] 2024-02-08T12:23:19.326Z permission info Sending request to OPA: http://localhost:8181/v1/data/policy type=plugin
[1] 2024-02-08T12:23:19.326Z permission info Sending input to OPA: {"permission":{"name":"catalog.entity.refresh"},"identity":{"user":"user:default/anderseknert","claims":["user:default/anderseknert","group:default/feedback-maintainers","group:default/kube-mgmt-chart-maintainers","group:default/opa-maintainers","group:default/setup-opa-maintainers"]}} type=plugin
[1] 2024-02-08T12:23:19.328Z permission info Permission request sent to OPA with input: {"permission":{"name":"catalog.entity.refresh"},"identity":{"user":"user:default/anderseknert","claims":["user:default/anderseknert","group:default/feedback-maintainers","group:default/kube-mgmt-chart-maintainers","group:default/opa-maintainers","group:default/setup-opa-maintainers"]}} type=plugin

This is quite chatty and logging the input at info level also reveals quite a lot in terms of potentially sensitive information. I'd suggest changing the log level of these events to debug. OPA has decision logging anyway so if I want to see which decisions were made I'd turn to those instead, and have the backstage plugin log only errors, at least at info level.

None of the README's have pre-requisite sections.

Based on feedback we should add some PRE-REQs to help people onboard.

Describe the bug
Main README needs some updates post using a docker compose file and entrypoints

To Reproduce
N/A

Expected behavior
Clearer instructions in the main readme.

Screenshots
N/A

Additional context
The readme in the actual wrapper plugin is fine, but the main readme needs updating.

The wrapper should be possible to use for custom plugins as well somehow.

Not sure how to go about doing this, will need to look into it some more.

This will save time when publishing new package versions.

As OPA could leverage any combination of ACL's, RBAC, ABAC, ReBAC or what have you, it seems unnecessary to limit the name of the permissions plugin in the opaClient config to rbac. I'd suggest using permissions instead.

Need to now send the user token with the request to the backend plugin to satisfy the requirements of the new Auth Services.