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

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

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

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.

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.

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

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.

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.

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.

The @backstage plugins need to be bumped and then released in all the OPA plugins.

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.

Quick Question/Feedback

Question or Feedback:
Hello. Just want to clarify. I am using RBAC plugin made by janus-idp. When I try to add OPA wrapper, Backstage fails. I want to use OPA wrapper to be able to create additional policies/permissions which I want to use with RBAC. Is it expected that app fails? In your docs, it is stated: "This plugin also requires and assumes that you have at least setup the permission framework (without any policies)".

Plugin Name:
@parsifal-m/plugin-permission-backend-module-opa-wrapper
@janus-idp/backstage-plugin-rbac-backend

Additional Details:
janus-idp RBAC plugin docs: https://github.com/janus-idp/backstage-plugins/blob/main/plugins/rbac-backend/README.md

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

Is your feature request related to a problem? Please describe.
Its quite hard for me now to manage the releases of each package in this monorepo, I've had a look at https://github.com/changesets/changesets and it seems to be the go-to for monorepos.

Describe the solution you'd like
Preferably https://github.com/changesets/changesets but open to other ideas.

Describe alternatives you've considered
None currently, most roads point to https://github.com/changesets/changesets

Additional context
N/A

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.
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.

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!

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

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

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.
No

Describe the solution you'd like
Some documentation and examples on how to use http builtin to for example fetch a users entity information in order to make more detailed rules.

Describe alternatives you've considered
N/A

Additional context
Imagine you want to build a rule based on an annotation that a user entity entity has, currently the permissions framework does not send the full user data, only the users name and claims.

Using the HTTP builtin, we can make a get request to the backstage catalog and fetch the users entity information like the metadata including annotations etc... which will be really useful for some rules.

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

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

Is the NPM OPA WASM worth trying?

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.

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

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.

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.

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.

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

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

Is your feature request related to a problem? Please describe.
Something that came to mind when looking into #218 is that if you fall back to say a deny/allow/fail you probably want to be notified that there could be an issue with OPA.

You could set a config value under here once we add policyFallback we could add another value maybe notifyGroup or/and notifyUser and have them receive notifications that there is an issue.

Describe the solution you'd like
Using the notifications framework and based on advice by @drodil we could do something like:

1. You can do it pretty easily to OPA plugin directly, you just need probably a config value that contains notification receivers in case of error and add notificationService as optional dependency to the plugin. For this you also probably need a scheduled task to check the status periodically.

2. If it makes sense to use the existing devtools plugin, that would require first a scheduled task to check for the endpoints (+ i would add support for caching as it's possible to generate quite a lot of requests to external systems with this) and secondly support for notifications

Describe alternatives you've considered
I think we can always go for Option 1 initially then also look at adding option 2 later on if we can.

Additional context
N/A

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

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 your feature request related to a problem? Please describe.
Kind of related to #205 need to add some more complex examples to help people use this easier.

Describe the solution you'd like
Would be nice (in the end) to have a github pages type thing with some good docs and examples, but just having a nice README maybe split up with rules for CATALOG, SCAFFOLDER.. etc.. would also be fine.

Describe alternatives you've considered
N/A

Additional context
Should also add references for regal as it really helps with policy writing and can really help people new to Rego and OPA to accelerate the adoption

Is your feature request related to a problem? Please describe.
The rest of the docs for the other plugins need to be added to the /docs folder as well.

Describe the solution you'd like
Nice docs site with github pages.

Describe alternatives you've considered
N/A

Additional context
README are fine, but docsify makes it a bit more presentable.

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

Is your feature request related to a problem? Please describe.
The issue is backstage will become crippled should the OPA server not be running, or is otherwise inaccessible. This is acceptable in some contexts, but it can be a critical problem in certain environments. In particular, it is a crucial issue blocking initial adoption of OPA in my organization, as concerns are raised about "what happens if OPA is down?".

Describe the solution you'd like
Some fallback or failsafe functionality. A simple option is a wildcard ALLOW policy in case OPA is inaccessible. Another option is falling back to a secondary permission policy implemented in Typescript. Ideally, this would be a configuration option to avoid causing undesired effects on existing projects that already implement the OPA Wrapper.

Describe alternatives you've considered
I've looked over through the code of he plugins, and plenty of Backstage documentation. There is no documented pathway to solve this without forking this plugin, as the Backstage-OPA plugins are exclusive with other permissions plugins (or an order of priority can't be established)

Additional context
I've been authorized to work on this issue by my company, and I'll try to have something to show by Saturday. I reached out to Parsifal-M on Mastodon and he said this would be an interesting feature to add. My implementation would seek to be of minimal impact to existing projects, and hopefully show an example of fallback policies.

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

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.

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

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

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

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.