Add authorization to all endpoints

[ds-lcapellino]

As a Trace-X admin, (ROLE_ADMIN)
I want to have all my endpoints secured via a Trace-X role,
so that my application is secured against unwanted access.

Blocker

We do not have a technical user on INT environments. Therefore, we need a concept how to authenticate (e.g. API key?)

Hints / Details

for example, is not secured with any role. This could be resolved with adding:
@PreAuthorize("hasAnyRole('ROLE_ADMIN', 'ROLE_SUPERVISOR', 'ROLE_USER')")

All endpoints of

traceability-foss/tx-backend/src/main/java/org/eclipse/tractusx/traceability/submodel/application/rest/SubmodelController.java

Line 50 in c746f1d

public class SubmodelController {

are unprotected.

Acceptance Criteria

• all endpoints need at least the ROLE_USER role for allowed usage (SubmodelController)
• Insomnia collection is updated and published to team members
• documentation is updated
• frontend provides additional view for triggering private api endpoints (sync, /api/registry/reload $assetId)
  • usage of C-X style guide
  • User feedback executing action - Reasonable message mapping http status code.

Out of Scope

• ...

[ds-mwesener]

Two issues for discussion

Issue 1:

Called from our Dataplane

FIRST APPROACH: These paths could be secured via network settings -> only access allowed within the cluster:

• /qualitynotifications/receive
• /qualityalerts/receive
• /qualitynotifications/update
• /qualityalerts/update
• /callback/endpoint-data-reference
• /internal/endpoint-data-reference

SECOND APPROACH: Alternatively, we could use the possibility of the EDC: EDC HTTP Data Plane.

This has never been tested and involves several processes, e.g., IRS data asset registration, Trace-X data ingest, GitHub Action Pipeline for setup of environments. Due to the high impact and complexity, the first approach (securing via network settings) is the preferred and more straightforward solution.

Issue 2:

Used by IRS to Send Job Completed Info

• /irs/job/callback

Currently, in IRS, there is no mechanism for authentication. It would be easy to work with a key within the jobRegistration. This key could be transferred to the /irs/job/callback address and validated to ensure that the request is acceptable.

Derived ticket for IRS for evaluation: eclipse-tractusx/item-relationship-service#740

Info from EDC team regarding usage of api key: https://matrix.to/#/!mYxOilDPMLCQhMoIVc:matrix.eclipse.org/$cCww_Sp9NEocHYou8rzvPFcxaBtFLEc-BHLr7ULH-DE?via=matrix.eclipse.org&via=matrix.org&via=dev-null.rocks

The api key solution is also involved in several process and therefore still the more effort solution.

[mkanal]

Issue 1:

OPTION: Using API Keys instead of OAuth 2.
FIRST APPROACH: In my understanding, this option does not fit the goal of this story to secure the api endpoints in general.
SECOND APPROACH: Here I need some more details to understand what is extended here.

[mkanal]

Target solution is to secure the endpoints via OAuth2 or API Key. We create a ticket for the target solution.
Now FIRST APPROACH will be implemented.

[ds-mwesener]

As discussed the following was defined:

Issue 1: We will use approach one and secure the apis to be only accessible within the kubernetes cluster.
As a long term solution we created a story: #1132

Issue 2: IRS will evaluate an approach of how they can accept a authentication parameter. So that trace-x can use it to secure the api..

[ds-mwesener]

No insomnia update required.
Internal accessible APIs are returning a 404 from outside of the cluster:

[ds-mwesener]

Added some documentation here:

• https://eclipse-tractusx.github.io/traceability-foss/docs/arc42/full.html#_safety_and_security_concepts

Added known known here:

• https://raw.githubusercontent.com/eclipse-tractusx/traceability-foss/main/CHANGELOG.md

[ds-crehm]

Tested on E2E: Cannot access endpoints through Insomnia. I get a 404 for all of them.

However, internal requests are failing as well. Sending notifications does not work currently and in the logs an identical error is mentioned: 2024-07-03T08:26:16.066Z WARN 1 --- [nio-8080-exec-7] o.e.t.t.c.config.TrustedEndpointsFilter : /api/internal/qualitynotifications/receive
2024-07-03T08:26:16.066Z WARN 1 --- [nio-8080-exec-7] o.e.t.t.c.config.TrustedEndpointsFilter : denying request for trusted endpoint on untrusted port

[ds-mwesener]

Hi @ds-crehm as discussed the public api should return 404 on the internal apis. I have fixed the behaviour that the notification callback apis used the wrong url. Now it should work please validate.

[ds-crehm]

Tested on dev/test & E2E: Notifications can be sent again now. Endpoints are properly secured.
Ready for review.

[mkanal]

LGFM PO acceptance in behalf of @jzbmw