Define function input schemas for operations with securitySchemes

What would you like to be added: An implicit schema should be defined for the function arguments based on the securitySchemes defined in the asyncapi/openapi operation.

Why is this needed: Different securitySchemes entail different types of inputs from the users. Eg: basic auth scheme in the openapi spec should translate to "username" and "password" input keys in the function arguments. The runtime should then handle them as defined by the openapi spec.

There could be different such expected inputs for different securitySchemes. Leaving these to the implementations could affect portability across runtimes, so there should be some behavior defined by the spec to handle these.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@paarthdassani First of all, sorry we could not address your issue sooner, we had our hands full with upcoming refactor.

As we are finishing up modelling the 1.0.0-alpha1, I want to make sure it covers what you need/are asking for.

An implicit schema should be defined for the function arguments based on the securitySchemes defined in the asyncapi/openapi operation.

What do you mean exactly with that? I'm not sure I understand. You want to add a way to set the parameters of the security scheme defined in the OpenAPI document? If so, then you probably hould use an authentication policy.

As of now, authentication in ServerlessWorkflow is declarative, not dynamic. This means that, even though you are calling an OpenAPI function that is documented to be protected by, say, basic authentication, Serverless Workflow mandates that you declare it as the function's authentication policy. As a result, runtimes should not pay attention to authentication mechanisms documented in the OpenAPI doc.

The main reason behind it is that, by definition, OpenAPI only documents said schemes, and does not, obviously, configure it, which forces you to declare some (potentially arbitrary) parameters (like username and password) in the function call... that's exactly what can be achieved using an Authentication Policy, which defines, for each supported scheme, the schemas I believe you are speaking about.

Thanks @ricardozanini for the response! Runtime relying on the authentication policy works.

@paarthdassani you meant @cdavernas? 🤣

Oops :) Thanks @cdavernas