Skip to content

Issue 394 restrict edgar api access - #570

Open
sdv-infy wants to merge 5 commits into
eclipse-opendut:developmentfrom
sdv-infy:issue-394-restrict-edgar-api-access
Open

Issue 394 restrict edgar api access#570
sdv-infy wants to merge 5 commits into
eclipse-opendut:developmentfrom
sdv-infy:issue-394-restrict-edgar-api-access

Conversation

@sdv-infy

@sdv-infy sdv-infy commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Restrict EDGAR API access via OAuth scopes (#394)
Implements scope-based authorization so EDGAR clients can only access the edge API (PeerMessagingBroker) and are blocked from all management API endpoints.

Tasks completed:
Create client scopes in Keycloak during provisioning (opendut-admin-api, opendut-edge-api)
Assign scopes to clients after registration, add OAuth scope to default scopes to indicate which API it is allowed to use:

  • EDGAR client: opendut-edge-api
  • CLEO client: opendut-admin-api
  • LEA client: opendut-admin-api

Peer messaging broker (Edge API) checks required scope opendut-edge-api
Administrative API checks required scope opendut-admin-api
I have tested my changes manually.

Comment thread opendut-carl/src/lib.rs
.add_service(grpc_facades.cluster_manager_facade.into_grpc_service())
.add_service(grpc_facades.metadata_provider_facade.into_grpc_service())
.add_service(grpc_facades.peer_manager_facade.into_grpc_service())
.add_service(grpc_facades.peer_messaging_broker_facade.into_grpc_service())

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason to move this line?

If yes, it should be documented...

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I think I messed it up a bit. I'll update it.

@sdv-infy
sdv-infy marked this pull request as draft August 5, 2026 14:16

@reimarstier reimarstier left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work on this PR — thanks for driving #394 forward so thoroughly. The overall direction (introducing dedicated scopes, assigning them during client setup, and enforcing them in CARL) is exactly what we needed and it’s a strong security improvement.

I only see a few follow-ups before merge:

  1. In opendut-carl/src/lib.rs, please remove the duplicate reqwest_client initialization (the first one is currently unused).
  2. For scope routing, replace u.path().contains("PeerMessagingBroker") with an exact/prefix match on the fully-qualified gRPC service path to avoid accidental misclassification.
  3. In opendut-auth/src/types.rs, since multiple values can be present, consider renaming the claim field to scopes (or otherwise making that intent explicit).

Thanks again — this is a really valuable contribution and very close to done.

Comment thread opendut-auth/src/types.rs Outdated
pub groups: Vec<String>,
/// OAuth scopes (space-separated string in the JWT)
#[serde(default)]
pub scope: String,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As written in the comment, there can be multiple scopes encoded. The field should also be named scopes.

Comment thread opendut-carl/src/lib.rs Outdated
};

let mut routes_builder = Routes::builder();
let reqwest_client = reqwest_client::oidc::create_from_config(&settings)?;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is a duplicate of the same line below.

Comment thread opendut-carl/src/lib.rs Outdated
let is_edge = request
.extensions()
.get::<axum::extract::OriginalUri>()
.map(|u| u.path().contains("PeerMessagingBroker"))

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This match is too broad; it should use an exact/prefix match on the fully-qualified gRPC service path (on OriginalUri) to avoid accidental scope misclassification if other paths ever include that substring.

- EDGAR requests edge-api scope for peer messaging
- CLEO/LEA request admin-api scope for admin operations
- metadata_provider accepts both scopes for version checks
- gRPC auth layer validates scope-based access control

Fixes eclipse-opendut#394
@sdv-infy
sdv-infy marked this pull request as ready for review August 12, 2026 08:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants