Access operation level or top-level security object

[ahx]

OpenapiFirst::Request#security should return information about the security scheme of the current operation and it's scopes/values. If no security scheme is defined for the operation, it should return the top-level security scheme if that is defined.

See specification: Operation, Security Scheme

[ahx]

I can only think of hypothetical use cases for now so I am closing this for now, but I am happy to implement this if anyone wants to use it.

[securepii-dev]

@ahx
I have a Roda app, using OpenAPIFirst middleware and then doing authentication in a Roda plugin. It means there is a slight quirk that the body is being checked for completeness before the auth is so if you pass bad body and no authentication, the result is 400 not the 401 I would expect.

My use case for this would be that the security is checked and rejected (with a 401) if the security data isnt validated.
i.e. if a security schema of BasicAuth is defined (see below) then the Authorization header is checked to see if it has been passed and that the value starts with "Basic" followed by a space and then data that only has base64 characters in it.

Much like checking the type parameters of a schema, it is checking the schema of the security scheme.

I could of course move the authentication to a rack middleware and put it in front of OpenAPIFirst but I think it would be a useful addition to this great piece of software.

components:
  securitySchemes:
    BasicAuth:
      type: http
      scheme: basic

[ahx]

the result is 400 not the 401 I would expect

Sorry, I am just skimming over this so I might miss something…
Why does the request result in a 400 response in your case?
Do you think authorization should be done first, then request validation? (makes sense to me).

[securepii-dev]

hi @ahx, I dont expect openapi_first to act as an alternative to rodauth or authentication framework, I see it as validation of the OpenAPI spec which includes details about what authentication types are valid for each path.

To answer your question "Why does the request result in a 400 response in your case?", I had a Rack middleware stack which had openapi_first followed by Roda. Roda had a basic authentication plugin configured.
In a test I was sending a bad body and no Authorization header. openapi_first was called, the body was validated and failed returning a 400. I believe this would be a surprise to users of my API as the authorization was also bad and a general assumption would be that the body wouldn't be validated before authorization. Practically there isnt a difference, the request was rejected, it is just I think the result would be surprising.

I think if openapi_first checked that the security scheme was valid for the path, then the query/body, it would be a useful enhancement. Note openapi-first shouldn't check the validity of the value of the security schema any more than it checks the validity of the body content. It does things like check that a string with format of email matches an email address not that it is the right email address i.e. the shape of the data not the content of the data.
If for example the basic scheme was applied to a path and the path matched, openapi_first would check for an Authorization header with the format "Basic ^([A-Za-z0-9+/]{4})*([A-Za-z0-9+/]{3}=|[A-Za-z0-9+/]{2}==)?$". If it matches, move on to check the query/body/etc otherwise fail.

I don't see a problem with failing at that point with a 400 response because the request is bad, especially with an error message saying "missing security scheme" or "bad security scheme". You haven't failed authorization, you have sent a bad request that doesnt match the specification. Once the data is the right shape, then something like Rodauth can do the authorization/authentication and potentially return 401.

[ahx]

Thanks for reply. This all makes sense. Do you want to work on a PR about this? – I can help out if you need input.

[securepii-dev]

I don't have a lot of time at the moment but I can work on it as I get a chance.
Could you point me to where in the source you think the check would go?
I am thinking request_validator.rb. If so, would I use Validators::RequestParameters or create a new one?

[ahx]

Yes, I think request_validator.rb is a good entrypoint. I think would put a new class next to validators::RequestParameters