Swagger - Adding multiple security parameters to the same schema definition - swagger

Aim
To include multiple security headers to every request made within the API
Problem
I am trying to add multiple headers to my Swagger YAML security definitions.
I have trawled though the API but not have alot of luck
But am finding that when making the 'Try-This-Operation' I am required to select one. Rather than able to use both. Is this correct or am I doing something incorrectly?
Snippet
securityDefinitions:
userEmail:
type: apiKey
name: User Email
in: header
clientId:
type: apiKey
name: Client Id
in: header
security: [ { userEmail: [], clientId: [] } ]
Alternative?
If I am trying to do this impossible ...
Is it possible to specify these parameters as default for all the rest paths within the swagger document?
I am new to Swagger this week any have found everything else without problem ... but I cannot find any good example of this.
If any guidance could be given that would be incredibly helpful
Many thanks

Your SecurityDefintions object looks ok. Beware that
security: [ { userEmail: [], clientId: [] } ]
means the API client MUST use userEmail authentication AND clientId authentication at once! You probably meant:
security: [ { userEmail: [] }, { clientId: [] } ]
which means the API client MUST use either userEmail authentication OR clientId authentication.
To avoid repeating this definition over and over again you can use the global security property that applies to all paths without their own security object:
security: [ { userEmail: [] }, { clientId: [] } ]
paths:
"/foo":
get:
post:
or make use of a reference for explicitness or for multiple common values:
paths:
"/foo":
get:
security:
"$ref": "#/definitions/lowSecurity"
post:
security:
"$ref": "#/definitions/highSecurity"
definitions:
lowSecurity: [ { foo: [] }, { bar: [] } ]
highSecurity: [ { foo: [] } ]
Reference
The Swagger2 specification states under Operation Object:
security:
[Security Requirement Object]
A declaration of which security schemes are applied for this operation. The list of values describes alternative security schemes that can be used (that is, there is a logical OR between the security requirements). This definition overrides any declared top-level security. To remove a top-level security declaration, an empty array can be used.
The Security Requirement Object is described like this:
Lists the required security schemes to execute this operation. The object can have multiple security schemes declared in it which are all required (that is, there is a logical AND between the schemes).
The name used for each property MUST correspond to a security scheme declared in the Security Definitions.

OAS 3: https://swagger.io/docs/specification/authentication/
Using Multiple Authentication Types
Some REST APIs support several authentication types. The security section lets you combine the security requirements using logical OR and AND to achieve the desired result. security uses the following logic:
security: # A OR B
- A
- B
security: # A AND B
- A
B
security: # (A AND B) OR (C AND D)
- A
B
- C
D

Related

role based token authentication with apikey security in openapi swagger connexion

Describing the problem
I was struggeling the last few days to figure out how to use apikey security in openapi, swagger, connexion for role based token authentication. The following OpenAPI 3.0 endpoint definition:
/lab/samples/list:
get:
tags:
- lab
summary: get a list of all registered samples
operationId: list_samples
responses:
"200":
description: successfully returned all available samples and their notification status
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/Sample-For-Lab'
x-content-type: application/json
"400":
description: invalid request
content:
application/json:
schema:
$ref: '#/components/schemas/inline_response'
security:
- bearerAuth: ['labuser']
with the corresponding security definition
securitySchemes:
bearerAuth:
type: apiKey
name: Authorization
in: header
x-apikeyInfoFunc: swagger_server.controllers.authorization_controller.check_bearerAuth
So far so good. I built the corresponding server stubs using swagger-codegen, which follow the connexion security model and provide two fields api_key i.e. the bearer token and 'required_scopes' i.e. which should contain 'labuser'. When accessing the endpoint, the controller function is called:
def check_adminuserAuth(api_key, required_scopes):
return {'sample_key' : 'sample_value}
While the bearer token is properly passed, required_scopes is None. So there's no way of actually validating if credentials and permissions shown in the provided token actually match the endpoint's required scope of labuser in the authorization controller. I thought about handling validation in the called endpoints list_systemusers() but the token is no passed on by connexion.
Not supported in OpenAPI 3.0
After doing some digging, I found out that OpenAPI 3.0 provides apiKey validation on a global API level (i.e. authenticated or not), but does not offer support for individual scopes per endpoint. If you want individual scopes, you need to switch to OAuth security. However support for security scopes through apiKey security is coming in OpenAPI 3.1
Workaround
So for now the only way of making bearer token security with individual scopes work, is to actually define a security scheme for every scope e.g.
securitySchemes:
adminuserAuth:
type: apiKey
description: Provide your bearer token in the format **Bearer <token>**
name: Authorization
in: header
x-apikeyInfoFunc: swagger_server.controllers.authorization_controller.check_adminuserAuth
statsuserAuth:
type: apiKey
description: Provide your bearer token in the format **Bearer <token>**
name: Authorization
in: header
x-apikeyInfoFunc: swagger_server.controllers.authorization_controller.check_statsuserAuth
labuserAuth:
type: apiKey
description: Provide your bearer token in the format **Bearer <token>**
name: Authorization
in: header
x-apikeyInfoFunc: swagger_server.controllers.authorization_controller.check_labuserAuth
and on the path definition then add your required security authentication schemes
security:
- labuserAuth: []
- adminuserAuth: []
x-openapi-router-controller: swagger_server.controllers.lab_controller
Now I know by which authorization controller method is called the required scope a user needs to show and therefore can validate it against the ones shown in the token.

Flask RESTPlus swagger interface doesn't pass Authorisation header on to curl request

Running latest (and now old due to the switchover to flask REST-X) flask RESTPlus using the authorization functionality for the swagger interface with a Bearer token as follows:
authorizations = {
'apikey': {
'type': 'apiKey',
'in': 'header',
'name': 'Bearer '
}
But although the "Authorise" box comes up in the swagger interface, and I can put a token in there, it doesn't get added to the requests coming out or the curl format that swagger provides, so we can see clearly it's not being picked up. What's going on here and how do I fix it?
Make sure the code also has annotations that would add security to individual operations or globally. This is needed to actually attach the Authorization header to operations.
In other words, the generated OpenAPI definition should contain the following.
If using OpenAPI 2.0:
swagger: '2.0'
securityDefinitions:
apikey:
type: apiKey
in: header
name: Authorization
security:
- apiKey: []
If using OpenAPI 3.0:
openapi: 3.0.0
components:
securitySchemes:
apikey:
type: apiKey
in: header
name: Authorization
# or using OAS3 Bearer auth scheme
# apiKey:
# type: http
# scheme: bearer
security:
- apiKey: []

Multiple Authentication "OR" not working in Google Cloud Endpoints OpenAPI

In Google Cloud Endpoints, I am unable to have authentication occur in an "or" scenario, where, for example, I want to allow access to a path by means of an api_key "or" oauth. Please see https://swagger.io/docs/specification/2-0/authentication/ for more info.
DOES WORK (single defintion for API key)
/api/query:
get:
operationId: queryget
responses:
'200':
description: query success
security:
- api_key: []
DOES WORK (single definition for oauth)
/api/query:
get:
operationId: queryget
responses:
'200':
description: query success
security:
- oauth: []
DOES WORK ("AND" definition where both must be included in auth)
/api/query:
get:
operationId: queryget
responses:
'200':
description: query success
security:
- oauth: []
api_key: []
DOES NOT WORK ("OR" definition)
/api/query:
get:
operationId: queryget
responses:
'200':
description: query success
security:
- oauth: []
- api_key: []
To be more specific when deploying my api to Google Cloud Endpoints, I receive the following warning
Operation 'get' in path '/api/query': Operation does not require an API key; callers may invoke the method without specifying an associated API-consuming project.
And, when trying to call the api with an API key, I receive the following error, as if it were expecting the OAUTH JWT token (maybe because it was the first security definition in the list for that route)
{ "code": 16, "message": "JWT validation failed: Missing or invalid credentials", "details": [ { "#type": "type.googleapis.com/google.rpc.DebugInfo", "stackEntries": [], "detail": "auth" } ]}'
This feature is unsupported, unfortunately. You can only use AND. This is now documented in Unsupported OpenAPI Features.

Zabbix LLD custom process monitoring item error

I want to track my custom processes through Zabbix (v2.4.8). I am generating the following json object and sending it through UserParameter=service.value[*],/usr/lib/zabbix/externalscripts/custom1.bash:
{
"data":[
{
"{#NAME}":"ntp",
"{#VALUE}":"1"
},
{
"{#NAME}":"mysql",
"{#VALUE}":"1"
},
{
"{#NAME}":"prometheus",
"{#VALUE}":"0"
},
{
"{#NAME}":"apache2",
"{#VALUE}":"0"
}
]
}
Also, creating an item prototype and graph prototype inside a new template with a new discovery rule, having the following information:
Discovery rule name: Service Graph
Type: Zabbix Agent
key: service.value
Item Prototype name: Service {#NAME} Graph
Type: Zabbix Agent
key: service.value[{#NAME},{#VALUE}]
Type of info: Numeric(Unsigned) & Decimal
When I apply these settings, the items keep giving the following error:
Not supported: Received value [{ "data":[ { "{#NAME}":"ntp", "{#VALUE}":"1" }, { "{#NAME}":"mysql", "{#VALUE}":"1" }, { "{#NAME}":"prometheus", "{#VALUE}":"0" }, { "{#NAME}":"apache2", "{#VALUE}":"0" } ]}] is not suitable for value type [Numeric (unsigned)] and data type [Decimal]
I have to create a graph prototype with these settings, so I cannot mention type as "Text" for obvious reasons.
Another question: The graphs thus generated are not clickable at all like the other existing graphs.
Please let me know where I am going wrong.
If your service.value key generates JSON, that should be used with the LLD rule only. You should not send any values in it. The key to be used in the prototypes should be like any normal key they only returns values it was asked for, do not use the LLD-generating key there.
Your current JSON looks like you might be able to use the built-in items for process monitoring, but that is hard to be sure about without additional detail.
Also note that [*] in the UserParameter definition is not needed if you do not pass parameters to this key.

How to specify a property can be null or a reference with swagger

How to specify a property as null or a reference? discusses how to specify a property as null or a reference using jsonschema.
I'm looking to do the same thing with swagger.
To recap the answer to the above, with jsonschema, one could do this:
{
"definitions": {
"Foo": {
# some complex object
}
},
"type": "object",
"properties": {
"foo": {
"oneOf": [
{"$ref": "#/definitions/Foo"},
{"type": "null"}
]
}
}
}
The key point to the answer was the use of oneOf.
The key points to my question:
I have a complex object which I want to keep DRY so I put it in a
definitions section for reuse throughout my swagger spec: values of other properties; response objects, etc.
In various places in my spec a
property may be a reference to such an object OR be null.
How do I specify this with Swagger which doesn't support oneOf or
anyOf?
Note: some swagger implementations use x-nullable (or some-such) to specify a property value can be null, however, $ref replaces the object with what it references, so it would appear any use of x-nullable is ignored.
OpenAPI 3.1
Define the property as anyOf of the $ref and type: 'null'.
YAML version:
foo:
anyOf:
- type: 'null' # Note the quotes around 'null'
- $ref: '#/components/schemas/Foo'
JSON version:
"foo": {
"anyOf": [
{ "type": "null" },
{ "$ref": "#/components/schemas/Foo" }
]
}
Why use anyOf and not oneOf? oneOf will fail validation if the referenced schema itself allows nulls, whereas anyOf will work.
OpenAPI 3.0
YAML version:
foo:
nullable: true
allOf:
- $ref: '#/components/schemas/Foo'
JSON version:
"foo": {
"nullable": true,
"allOf": [
{ "$ref": "#/components/schemas/Foo" }
]
}
In OAS 3.0, wrapping $ref into allOf is needed to combine the $ref with other keywords - because $ref overwrites any sibling keywords. This is further discussed in the OpenAPI Specification repository: Reference objects don't combine well with “nullable”
Not easy to do that. Even almost impossible. Your options :
Wait
There is a very long discussion about this point, maybe one day it will be done...
Use vendors extensions
You can use vendors extensions like x-oneOf and x-anyOf. I have already taken this hard way: You must to upgrade all used 'swagger tools' to take into account these vendors extensions.
In my case, we needed 'only' to :
Develops our own Jax-RS parser with customized annotations in order to extract swagger API file from sources
Extends swagger-codegen to take into account these extensions to generate java code for our clients
Develops our own swagger-ui: to facilitate this work, we added a preprocessing step to convert our swagger schema with our extensions to a valid json schema. It's easier to find a module to represent json schemas than swagger schemas in javascript. By cons we gave up the idea to test the API with the 'try it' button.
It was a year ago, maybe now ...
Refactor your APIs
Many projects don't need anyOf and oneOf, why not us ?
For OpenAPI 3.0 for some reason using nullable: true followed by allOf didn't work for the OpenAPI interpreter I'm using. As a workaround I ended up defining a must-be-null ref called null_type that I can use in an anyOf construct.
Like so:
allOf:
- anyOf:
- $ref: "#/components/schemas/null_type"
- $ref: "#/components/schemas/your_ref"
- description: "optionally add other properties here..."
where:
schemas:
null_type:
title: "OpenAPI 3.0 null-type ref"
description: "for adding nullability to a ref"
enum: [null]
your_ref:
...

Resources