Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

On the Home Ribbon, Click API Options and choose OpenAPI ConfigurationImage Removed

...

This will open a new designer tab where you can configure several options, such as your API Explorer title bar information and API Security configuration.

To learn more about OpenAPI, see

...

their documentation

...

page for version 3.0.3.


We are concerned with the following 3 sections of this json file:

  • The "x-allowAnonymous" property.  Set this property to true to enable anybody to call your APIs.

  • The "security" section.  This section is where you define what security schema are to be checked when an API is called.

    • These securities are applied to all APIs however a specific API route can override these securities.

    • Advanced: Notice that this section is an array of objects.  It does allow for configuring multiple schemas within each array element

    • See 

      See here for even more information.

{name}

[]

Each

name 

name MUST

 correspond

 correspond to a security scheme which is declared in

the 

the Security Schemes

 under the 

 under the Components Object. The

array 

array MUST

 be

 be empty.


Field Name

Type

Applies To

Description

type

string

Any

REQUIRED. The type of the security scheme. Valid values

are 

are "apiKey" or "http".

description

string

Any

A short description for security scheme. CommonMark syntax MAY

 be

 be used for rich text representation.

name

string

apiKey

REQUIRED. The name of the header, query or cookie parameter to be used.

in

string

apiKey

REQUIRED. The location of the API key. Valid values

are 

are "query", "header"

 or 

 or "cookie".

scheme

string

http

REQUIRED. The name of the HTTP Authorization scheme to be used in the Authorization header as defined in [RFC7235]. The values

used 

used SHOULD

 be

 be registered in

the 

the IANA Authentication Scheme registry.

x-ibmi

boolean

http

Set this property to true if this security scheme is for IBMi user/password credentials.


This configuration is case-sensitive and must be a valid JSON document.

Examples


Below is a simple example of a single security using a single scheme.  This example is using API Key Authentication.

  • The "name" of the security scheme can be anything, below the name this one "MyAPIKey".

  • Notice that "MyAPIKey" is defined as an "apiKey" type, and requires a property named "X-API-KEY" in the header.

  • Also, to enable this scheme authentication, it must be included in the "security" section and the name must exactly match.

With the below configuration, this means when an API is called the caller must send a header with a property called "X-API-KEY".

The API Framework will attempt to authenticate to a single user with that "X-API-KEY" value.
 An example of a configuration that secures all APIs to require an API key credentials

{
  "openapi": "3.0.3",
  "info": {
    "title": "My Company APIs",
    "version": "1.0.0"
  },
  "components": {
    "securitySchemes": {
      "MyAPIKey": {
        "type": "apiKey",
        "in": "header",
        "name": "X-API-Key"
      }
    }
  },
  "x-allowAnonymous":

 false

 false,
  "security": [
    {
      "MyAPIKey": []
    }
  ]
}

Below is another simple example of a single security using a single scheme.  This example is using User/Password Authentication.

  • The "name" of the security scheme can be anything, below the name this one "User".

  • Notice that "User" is defined as a "http" type with scheme basic.  This means it requires the caller to send an encoded basic User/Password value for "Authorization" in the header.

  • Also, to enable this scheme authentication, it must be included in the "security" section and the name must exactly match.

With the below configuration, this means that when an API is called the caller must include a header with a property called "Authorization" that contains a standard encoding of basic user:password.

The API Framework will then attempt authenticate to a single user profile that matches the encoded credentials.
 An example of a configuration that secures all APIs to require User/Password credentials

{
  "openapi": "3.0.3",
  "info": {
    "title": "My Company APIs",
    "version": "2.1.6"
  },
  "components": {
    "securitySchemes": {
      "User": {
        "type": "http",
        "scheme": "basic"
      }
    }
  },
  "x-allowAnonymous":

 false

 false,
  "security": [
    {
      "User": []
    }
  ]
}


Below is another simple example of a single security using a single scheme.  This example is using IBMi User/Password Authentication..
 An example of a configuration that secures all APIs to require IBMi User/Password credentials

{
  "openapi": "3.0.3",
  "info": {
    "title": "My Company APIs",
    "version": "2.1.6"
  },
  "components": {
    "securitySchemes": {
      "IBMiUser": {
        "type": "http",
        "scheme": "basic",
        "x-ibmi":

 true

 true
      }
    }
  },
  "x-allowAnonymous":

 false

 false,
  "security": [
    {
      "IBMiUser": []
    }
  ]
}

Multiple Security Schemes

Below is an example that shows how you can use multiple schemes.

  • In the "security" section, there is still a single array element, however there it has two properties: "AppKey" and "ClientID"

With the below configuration, this means when an API is called the caller must send a header with a property called "AppKey" and another property called "ClientID".

The API Framework will attempt to authenticate to a single user with both the "AppKey" and "ClientID" values.

 An An example of a configuration that secures all APIs to require two API credentials. (A AND B).

{
  "openapi": "3.0.3",
  "info": {
    "title": "My Company APIs",
    "version": "2.1.6"
  },
  "components": {
    "securitySchemes": {
      "AppKey": {
        "type": "apiKey",
        "in": "header",
        "name": "AppKey"
      },
      "ClientID": {
        "type": "apiKey",
        "in": "header",
        "name": "ClientID" 
      }
    }
  },
  "x-allowAnonymous":

 false

 false,
  "security": [
    {
      "AppKey": [],
      "ClientID": []
    }
  ]
}


Below is an example that shows using multiple schemes, where a request valid for EITHER AppKey OR ClientID would be permitted:

Code Block
{
  "openapi": "3.0.3",
  "info": {
    "title": "My Company APIs",
    "version": "2.1.6"
  },
  "components": {
    "securitySchemes": {
      "AppKey": {
        "type": "apiKey",
        "in": "header",
        "name": "AppKey"
      },
      "ClientID": {
        "type": "apiKey",
        "in": "header",
        "name": "ClientID"
      }
    }
  },
  "x-allowAnonymous": false,
  "security": [
    {
      "AppKey": [],
    },
    {
      "ClientID": []
    }
  ]
}