Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove empty security scheme #204

Open
AxelNennker opened this issue May 15, 2024 · 12 comments
Open

remove empty security scheme #204

AxelNennker opened this issue May 15, 2024 · 12 comments
Labels
correction correction in documentation Spring25

Comments

@AxelNennker
Copy link
Contributor

Problem description

In OAI {}denotes empty security.

From the spec:

A declaration of which security mechanisms can be used across the API. The list of values includes alternative security requirement objects that can be used. Only one of the security requirement objects need to be satisfied to authorize a request. Individual operations can override this definition. To make security optional, an empty security requirement ({}) can be included in the array.

From notification-as-cloud-event.yaml

security:
    - notificationsBearerAuth: []
    - {}

Expected behavior
No Camara API should have empty security.

Alternative solution
Remove empty security from all Camara yaml files, esspecially those in Commonalities.
notification-as-cloud-event.yaml

@AxelNennker AxelNennker added the correction correction in documentation label May 15, 2024
@rartych
Copy link
Collaborator

rartych commented May 16, 2024

@AxelNennker the notification-as-cloud-event.yaml is the helper artifact that shows how the notification receiver can be implemented by API Consumer.
The event notification endpoint is used by the API server to notify the API consumer that an event occurred.
It is not the specification of CAMARA API.

I think, the empty security scheme is added deliberately here , as it is up to API Consumer what security scheme he uses for receiving notifications.

I propose to close this issue or transform it to improve the description to clarify the security of notification-as-cloud-event.yaml.

@AxelNennker
Copy link
Contributor Author

@AxelNennker the notification-as-cloud-event.yaml is the helper artifact that shows how the notification receiver can be implemented by API Consumer. The event notification endpoint is used by the API server to notify the API consumer that an event occurred. It is not the specification of CAMARA API.

As I said, I think no Camara API should have no-security.
API-Subgroups are going to copy the lines from this artifact and then clients think they can subscribt without any authorization.

I think, the empty security scheme is added deliberately here , as it is up to API Consumer what security scheme he uses for receiving notifications.

I don't understand. It is for the API subgroup to decide which security is implemented and THEN the client can choose if there are multiple.
But I think that Commonalities should recommend which security scheme to use.
And I think there should only be two:

  • openid connect authorization code flow if the notification is about one user. Maybe the user opts out?!
  • openid connect client authentication with private_key_jwt if the notifications are send for any user

The current "recommendation" here is:

  securitySchemes:
    notificationsBearerAuth:
      type: http
      scheme: bearer
      bearerFormat: "{$request.body#/webhook/notificationAuthToken}"

bearer does not say how the token is generated or retrieved.
I do not understand the intention here. The Camara AZ knows all the clients, their client_id s, their public keys for various purposes, whatever. The AZ should create the bearer token. It is an access token created by the AZ, right?
Is this just a placeholder where the subproject has to define their own security scheme? Strange.

Maybe there should be an new issue on the security schemes?

I propose to close this issue or transform it to improve the description to clarify the security of notification-as-cloud-event.yaml.

Please clarify.

Ceterum censeo no security esse delendam

@AxelNennker
Copy link
Contributor Author

Maybe I am misunderstanding this completely and your intention is the other way around.
This is not for subprojects but for clients.
Still

  • no security is bad.
  • How does Camara create the bearer token?

@AxelNennker
Copy link
Contributor Author

I was/am thinking along the lines of CIBA. The client requests to receive notifications and sends an register-for-notifications event authenticated by some client authentication. Then when the event happens the telco sends the notification to the client's endpoint.

Anyway, some clarification is needed.

@rartych
Copy link
Collaborator

rartych commented May 16, 2024

@AxelNennker It looks that guidelines changes in PR #198 clarify the security of notifications.
I think the https://github.com/camaraproject/Commonalities/blob/main/artifacts/notification-as-cloud-event.yaml should be changed accordingly and its purpose should be stated more explicitly.
@patrice-conil @bigludo7 WDYT?

@PedroDiez
Copy link
Collaborator

The fact of indicating empty security is deliberate in order to not force an API consumer to provide a security mechanism.

security:
    - notificationsBearerAuth: []
    - {}

In case it provides one security mechanism, it is up to the API consumer its generation. So the "notificationsBearerAuth" schema.
That is the current approach.

This issue opens several points: (that we will need to discuss)

  • Avoid empty security for Notifications. On other words, making securization mandatory
  • Define the possible securization methods allowed
  • Define how the API consumer obtain tokens

@AxelNennker
Copy link
Contributor Author

Specifying the need for "something-something-bearer-token" is not enough, I think.

Camara is the source and, as currently specified, needs to send the authorization that is the bearer token.

I assume Carama does not want to become a client to the API Cosumer's AZ which would be one option to retrieve an access token that is then send as a bearer token.

Nobody should setup an endpoint with no security. See e.g. Zero Trust
The IT Industry has been there when it was enough for one server and second to be in e.g. a DMZ and trusted each other.
Not any longer. Not even inside (telcos) internal systems networks should there be blind trust.

Some might have the view "What should Camara care if the API consumer not protected?"

I say that we must care and we should not send notifications from telco/Camara systems to some insecure system.
A sink without access control could be swamped with notifications from any source.
A sink without access control could receive notifications from anywhere and think the notifications are originating from a Camara server. If the sink draws the wrong conclusions from those fake notifications then some might put blaime on Camara/telcos regardless of whether we are to blaim or not.

What are the options?

  • We could sign all notifications, publish our notification_signing_key and notification_signature_alg in some .well-known/notification-configuration.json Thus mitigating some of the threat.
  • We could create our own jwt-signed access token and have unsigned notifications
  • We could do both
  • <your idea here>

@PedroDiez
Copy link
Collaborator

Discussion is fair, however we need to agree first in which direction we move on and, if we have room and agree to address within Meta-Release Fall24.

Currently, we as "CAMARA" allow the "API Consumer" endpoint to be optionally protected, and in case it is protected, API Consumer indicates within "notificationAuthToken" (what it would be sinkCredential concept, ACCESSTOKEN type)

  1. First point is to reach agreement in Commonalities and its roadmap about mandating securization of notifications (requirement for API Consumer)

    • NOTE: In this context I also assume in principle that Carama does not want to become a client to the API Consumer's AZ.
      Because in that case it makes no sense for the API Consumer to indicate the securization in the request and this put requirements in both sides: API Consumer in order to expose an AZ Server and Telco Operator in order to interact with it and get a Token.
  2. Second Point, separated from above it is about which securization enable. So far, "ACCESSTOKEN" was considered to be aligned with the fact API Consumer indicates and oAuth2 Token.

@AxelNennker
Copy link
Contributor Author

Please see my comment #198 (comment)

It is not in Camara's interest to ignore the security of the API consumer.
It is in our interest that only the API consumer can create an access token that is e.g. like an CAMARA Security and Interoperability Profile

@AxelNennker
Copy link
Contributor Author

Please see #198 (comment)

I think the empty security scheme should be removed and the guideline should not suggest to API consumers that "credentials are not needed".

@eric-murray
Copy link
Collaborator

@AxelNennker

I think the empty security scheme should be removed and the guideline should not suggest to API consumers that "credentials are not needed".

When the notification structure was being developed in Quality on Demand, the original proposal was to "force" the API consumer to specify a "token" (an arbitrary string), which would be included in an Authorization: Bearer header with each notification. So the API consumer could generate a genuine token for the server, and validate it against their own authorisation server. Or they could specify a "fake" token that they just ignored. It was up to them.

But the objection was raised that we shouldn't pretend it was a bearer token if it was not, and hence the explicit option to have "no security" (notifications are always sent using TLS, of course) was included. This also slightly reduces the size of the notification, as no Authorization header is required.

Of course, the API consumer could still provide a fake token if they wished. So, by removing the "no security" option (and assuming that the very same objection was not raised again), we would be back to that being the only option for API consumers who do not want to validate the token in any notifications.

I don't mind that, though I don't see what is really being achieved, other than to inconvenience the API consumer slightly more by forcing them to specify a fake token they then ignore rather than none at all. And we would need to improve the documentation, as giving the impression that we require the API consumer to maintain an OAuth server in order to receive notifications (even though not true) would put many off using CAMARA APIs.

@PedroDiez
Copy link
Collaborator

The key point here is that, if we agree from Commonalities point of view that Notifications MUST be secured, then we are implicitly saying that the API consumer has to provide that token when creating the subscription (instance-based or resource-based)

cc @jlurien

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
correction correction in documentation Spring25
Projects
None yet
Development

No branches or pull requests

4 participants