When you select the "Security" tab in an API Version, you get a rich set of options for customizing security for your API.

Subscriptions and Security

If subscriptions to your API is required, clients will not be allowed to call your API unless they have authenticated - if subscriptions are not required, clients might be allowed to call the API unless you have specified any restrictions in the authorization settings.

Note that none of the authentication options are considered to be mandatory, they are treated as options for providing credentials - in case no credentials are supplied matching any of the enabled authentication mechanisms, Authorization options and subscription decides if the API is accessible or not.

In other words, you should only turn subscription off if you intend to allow anonymous access to your APIs, or you should configure the API Gateway to authenticate using some other means (see Setting up API Gateway) for information.

Available Authentication Methods

API-Key

API-Key is the simplest form of authentication - your API Partner Applications have one or more API keys defined for them - and any given one of them identifies that API Partner Application as the caller. Note that this API key should be treated as a secret password, which it essentially is.

Client Credentials / Basic Authentication

By enabling basic authentication, you enable your API Partner Applications to authenticate by providing their client_id and client_secret as userid/password in a Basic Authentication. Note that as usual, you should in the Ceptor Gateway ensure that all only https/encrypted connections are used.

SSL / TLS Client Certificate

If you enable SSL/TLS Client Certificate, any eventual client certificate is authenticated for this API call - this certificate must then match one of the configured certificates for an API Partner Application.

Bearer Authentication

This enables authentication using a bearer token, an access token earlier issued using OpenID Connect / OAuth2.

OAuth2 Authentication

Essentially the same as bearer authentication, but provides the OAuth2 authorize and token URLs in the OpenID Configuration, and allows specifying which scopes to require.

OpenID Connect Authentication

Again, almost the same as OAuth2 authentication, but exposes the OpenID Connection configuration metadata URL in the OpenAPI definition - that URL is usually https://www.yourorganisation.com/.well-known/openid-configuration

OpenAPI specification version 2 does not support OpenID Connect - so you cannot use this option unless you are using OpenAPI version 3 to specify your API.

You specify the appropriate OAuth2 / OpenID Connect URLs for each environment in API Management Configuration.

Advanced

If you click the "Advanced" button, it will expand like this:

Here, you have the chance to do more advanced authentication than normally - this script you can run here is called no matter if the request is already authenticated or not - and allow you to perform additional authentication or use custom authentication methods.

You can find more information and an example in the online help.

Using Other Forms of Authentication

Other options are available

Note that the options above affect what is published in the OpenAPI definition for your API, and if authentication is not already done when your API is about to be called, it affects which attempts will be tried given the proper credentials are supplied.

But, with Ceptor this is not your only option - you can secure your APIs anyway you want using e.g. SPNEGO / Kerberos or other means of authentication if you just set it up in the API Gateway - see Setting up API Gateway for details.

Authorization

As with any Location in the Ceptor Gateway, you can specify detailed authorization requirements per API or API operation.

Authorization

OPTIONS method bypasses authorization

Check this if you do not want to attempt authorization for OPTIONS requests - this is required for CORS preflight requests to work in most browsers. Do take care to ensure you are not allowing access to anything you do not mean to, although the OPTIONS method in itself should be perfectly safe.

Required Roles

List of roles/groups - if any roles are specified, at least one of them is required to access the resources.

Server Identifier

Server identifier - used for additional role checking where an authorization plugin in the session controller might specify additional protected URLs that require other roles than these listed above. - set to "none" to disable.
An Authorization plugin in the session controller keeps track of protected URLs for different identifiers, so it might be configured with other protected resources than you have here - if the server id is not set to "none" then the authorization plugin is consulted too.

Permission Name

Specify a permission that you need to have to get access to this location. See Authorization for more information.

Permissions and ACLs can contain very advanced functionality, such as ABAC (Attribute-Based Access Control) - see Authorization for more information. Note that some of these might result in a performance overhead.

You can always check the Gateway Tracing to see the details about each request and diagnose any performance issues.

Scope Name

If a Scope Name is defined, this scope needs to be in the OAuth2 bearer token access/token.

IP Range

Point to a configured IP range if the client needs to be in the range in order to access the API.

Authorization Script

Script which can do custom authorization - the script must return true or false.
See Plugins - AuthorizationScript for an example.

Overriding Security per Operation

It is possible to override the settings for each individual operation - in that case, just check the override box for the operation you want to override the settings for:

When checked, settings per operation appear like this:

For OpenAPI definitions loaded from remote, you need to specify security on the API level, not the operation level.