Feature: use decorators for admin api authentication

[esune]

Resolves #2318

Opening draft PR early for feedback while I work through the changes across the code (and fixing/updating/adding tests as needed).

The PR removes the authentication middleware and the logic they deal with, and implements two decorators:

• admin_authentication: to be used for routes that should ONLY be invoked by an administrator, such as the multitenancy endpoints, the server endpoints and so on, independently of the mode the agent is running as.
• tenant_authentication: to be used to require authentication by either providing a tenant token (multi-tenant mode) or a valid api-key (single-tenant mode).

Both decorators account for unauthenticated options requests as well as insecure mode. Insecure paths will just not be decorated. Middleware code - currently commented-out - will be removed.

I think the bit of refactoring required for this to work (including plugins once released) is well worth the flexibility - looking for early feedback especially from @dbluhm, @ianco, @jamshale

[ianco]

Looks good upon first glance.

[esune]

Looks good upon first glance.

Thanks @ianco . I've pushed updates to all the route handlers, now working on cleaning-up and fixing/adding tests and validating things really work as expected.

[dbluhm]

I like the flexibility and straightforward-ness of the approach. I like a nice function decorator lol. I always tend toward caution with them though; they can have some gotchas. Where these are being called by the aiohttp router, I think the gotcha potential should be minimal. LGTM so far.

[amanji]

So far, this all LGTM! Really liking how clean those decorators are.

[esune]

Fixed the route tests, still need to tackle removing the now failing middleware tests and add tests for the decorator functions.
Unsure why the formatter check is failing as it looks (to me) like the change it suggests is the same as the change that is already there?

[esune]

All tests should be fixed now. I updated/synced the version of Black as three different versions were specified between pyproject.toml, .pre-commit-config.yaml and blackformat.yml and ran the formatter on the project, however it still raises potential changes - if anyone has an idea of why/how to address this please let me know.

Only thing left now is adding tests specific to the decorators.

[jamshale]

All tests should be fixed now. I updated/synced the version of Black as three different versions were specified between pyproject.toml, .pre-commit-config.yaml and blackformat.yml and ran the formatter on the project, however it still raises potential changes - if anyone has an idea of why/how to address this please let me know.

I haven't looked into the pre-commit or black format files. I use the ruff vscode extension to format my files and it seems to work well with the project. If I do get a fail from black on the PR I use the Run and Debug black or ruff process from the devcontainer and it re-formats the code correctly for me.

[esune]

This is - finally - ready for review.

[jamshale]

There's one failing unit test because of a ruff formatting error. aries_cloudagent/config/argparse.py:650:91: E501 Line too long.
You can just add # noqa: E501 to the end of that line.

[jamshale]

Looks good and I will approve. I just had one comment about how there is a upgrade on all packages. I think it's better to only upgrade the packages related to the PR and do a general upgrade in a separate PR. In the case we do find a problem with an upgrade it will be easier to isolate.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud