Security Configuration

You must have the API Gateway’s manage security configurations functional privilege assigned to perform the following tasks in the security configuration section of API Gateway:

  • Configure the keystores and truststores required for incoming message-level security and transport-level security.

  • Configure the SAML issuer to use in API Gateway outbound authentication to fetch the SAML token from the STS (Security Token Service).

  • Configure the custom assertions to use in inbound authentication of API Gateway.

  • Configure Kerberos settings.

  • Configure JSON web token (JWT), OAuth, and OpenID authorization servers and third-party providers.

Keystore and Truststore

Keystores and truststores are secure files with industry-standard file formats. The keystore file stores the private keys and SSL certificates and the truststore file stores the trusted roots for the certificates.

A keystore file contains one or more pairs of a private key and signed certificate for its corresponding public key. The keystore should be strongly protected with a password, and stored (either on the file system or elsewhere) so that it is accessible only to administrators.

The truststore file functions as a database containing all the public keys for CAs within a specified trusted directory.

To enable the two-way SSL for an API Gateway service, you must add a valid, authorized X.509 certificate along with the private key in a keystore file, and the certificate of the client or partner in the truststore file. These keystore and truststore files have to referred to in the HTTPs port that is used to access the API Gateway service.

API Gateway has a sample keystore that contains self-signed certificates. Software AG recommends not to use them for configuring SSL communication with API Gateway in a production environment.

Configuring Keystore Information

  1. Expand the menu options icon icon, in the title bar, and select Administration.

  2. Select General > Security.
    A list of existing keystores and truststores and corresponding details are displayed.

  3. In the Keystores section, click Add keystore.

  4. In the Create keystore section, provide the following information:

    Field Description
    Alias A text identifier for the keystore file.

    The alias name can contain only letters, numbers and underscores. It can not include a space, hyphen and special characters.

    The keystore contains the private keys and certificates (including the associated public keys) for an Integration Server, partner application, or Integration Server component.
    Select file Select a keystore file of the specified type using Browse. Select the required file and upload it.
    Password Password for the saved keystore file associated with this alias.
    Type The certificate file format of the keystore file, which by default is JKS for keystores. You can also use PKCS12 format for a keystore.
    Description Optional. A text description for the keystore alias.
  5. Click OK.
    All the key aliases in the uploaded file are listed.

  6. Type a password for the required key alias.

  7. Click Save.
    The keystore is configured and the alias listed in the keystore alias table.

    Note: If a wrong password has been provided for the keystore or one of its aliases, API Gateway saves the keystore but it is not loaded. The keystore alias is displayed as the loaded icon with an X mark in the keystore listing.

Modifying Keystore Information

  1. Expand the menu options icon icon, in the title bar, and select Administration.

  2. Select General > Security.
    A list of keystores and truststores and corresponding details are displayed.

  3. Click the keystore alias to be updated.
    The update keystore section is displayed.

  4. Modify the fields as required.

  5. Click Save.
    The set of available aliases is displayed.

    Note: If the keystore file is not updated during the edit, then clicking Save closes the form. If a different keystore file is uploaded, then the list of aliases in the file is loaded and you are prompted to configure the passwords for the aliases.

  6. Type a password for the alias to be configured.

  7. Click Save.
    The keystore is updated.

Deleting Keystore Information

Be careful while deleting the keystore information. If the keystore and one of its key aliases is configured in the keystore settings and the keystore gets deleted, then the configuration would have issues.

To delete keystore information

  1. Expand the menu options icon icon, in the title bar, and select Administration.

  2. Select General > Security.
    A list of keystores and truststores and corresponding details are displayed.

  3. Click icon in the action column of the keystore to be deleted.

  4. Click Yes in the confirmation dialog.
    The keystore is deleted from the list.

Configuring Truststore Information

  1. Expand the menu options icon icon, in the title bar, and select Administration.

  2. Select General > Security.
    A list of existing keystores and truststores and corresponding details are displayed.

  3. In the Truststores section, click Add truststore.

  4. In the Create truststore section, provide the following information:

    Field Description
    Name A name for the truststore file.

    The alias name can contain only letters, numbers and underscores. It can not include a space, hyphen and special characters.

    The truststore contains the trusted CA certificates for an Integration Server, partner application, or Integration Server component.
    Upload truststore file Select a truststore file of the specified type using Browse. Select the required file and upload it.

    Note: Supports only JKS file format.
    Password Password that is used to protect the contents of the truststore.

    This password must have been defined at truststore creation time using a keystore utility.

    Make sure you have the truststore password available when managing its corresponding truststore alias.
    Description Optional. A text description for the truststore alias.
  5. Click Save.
    The truststore is configured and the alias listed in the truststore alias table.

    Note: If a wrong password has been entered for the truststore, API Gateway saves the truststore but it is not loaded. The truststore alias is displayed as the loaded icon with an X mark in the truststore listing.

Modifying Truststore Information

  1. Expand the menu options icon icon, in the title bar, and select Administration.

  2. Select General > Security.
    A list of keystores and truststores and corresponding details are displayed.

  3. Click the truststore alias to be updated.
    The update truststore section is displayed.

  4. Modify the fields as required.

  5. Click Save.
    The truststore is updated.

Deleting Truststore Information

Be careful while deleting the truststore information. If the truststore settings and the truststore gets deleted, then the configuration would have issues.

To delete keystore information

  1. Expand the menu options icon icon, in the title bar, and select Administration.

  2. Select General > Security.
    A list of keystores and truststores and corresponding details are displayed.

  3. Click icon in the action column of the truststore to be deleted.

  4. Click Yes in the confirmation dialog.
    The truststore is deleted from the list.

Configuring Keystore and Truststore Information for Inbound Messages

API Gateway includes a list of SSL keystores and truststores.

You might want to configure API Gateway to refer to a default keystore, truststore, or both, before deploying any SOAP message flows that require signature, encryption, X.509 authentication, and so on, as configured in the Inbound Authentication - Message policy. The default keystore and truststore are that you want API Gateway to use for the incoming secured messages.

To configure Keystore and truststore settings for inbound messages

  1. Expand the menu options icon , in the title bar, and select Administration.

  2. Select General > Security. A list of existing keystores and truststores loaded during startup and those created in API Gateway and corresponding details appears.

  3. To configure API Gateway’s default keystore and truststore alias for incoming secured messages, provide the following information in the Configure keystore and truststore settings section:

    Field Description
    Keystore alias Select a keystore that API Gateway uses for incoming message-level security. Lists all available keystores. If you have not configured any keystore, the list is empty.
    Key alias (signing) Select the alias for the private key to sign the outgoing response from API Gateway to the original client. This alias value validates the inbound requests to API Gateway and signs the outgoing response from API Gateway to the original client. It is auto-populated based on the keystore selected. This field lists all the aliases available in the chosen keystore. If there are no configured keystores, this field is empty. This field is auto-populated based on the selected keystore alias. It lists all the aliases available in the chosen keystore. If there are no configured keystores, this field is empty.
    Truststore alias The alias for the truststore that contains the list of CA certificates that API Gateway uses to validate the trust relationship with the client.
  4. Click Save.

Post-requisites: While securing the SOAP APIs using WS-Security policies, perform the following:

 a. Restart the server after configuring keystore and truststore information for the configuration to take effect.

 b. Deactivate the APIs that have Inbound Authentication - Message policy enforced.

 c. Update the keystore and truststore configuration.

 d. Activate the APIs that were deactivated.

Configuring Keystore and Truststore Information for Outbound Connections

You might want to configure API Gateway to refer to a default truststore that you want API Gateway to use for securing outgoing SSL connections. The keystore and key alias can be configured for outgoing two-way SSL connections. During the SSL handshake between API Gateway and the native API, the server certificate, which is sent by the native API, has to be validated against a truststore in API Gateway.

To configure keystore and truststore settings for outbound secured connections

  1. Expand the menu options icon , in the title bar, and select Administration.

  2. Select General > Security. A list of existing keystores and truststores loaded during startup, and those created in API Gateway and the corresponding details appears.

  3. To configure API Gateway’s default keystore and truststore alias for outgoing secured connections, provide the following information in the Configure keystore and truststore settings for outbound connections section:

    Field Description
    Keystore alias Select a keystore that API Gateway uses for outgoing secured connections. Lists all available keystores. If you have not configured any keystore, the list is empty.
    Key alias Select the alias for the private key for an outbound connection from API Gateway to the native API. This field is auto-populated based on the selected keystore alias. It lists all the aliases available in the chosen keystore. If there are no configured keystores, this field is empty.
    Truststore alias The alias for the truststore that contains the list of CA certificates that API Gateway uses to validate the trust relationship with the native API.
    If you do not configure any truststore alias, it implies that API Gateway does not validate the certificates provided by native APIs.
  4. Click Save.

Global IP Access Settings For Ports

This section describes how to specify the global IP access setting for ports. Here you can restrict the client IP address based on the authentication failure in API Gateway.

Configuring Restriction to IP Address based on Authentication

You must have the Manage Security Configuration functional privilege to configure this restriction.

You can configure the restriction to client IP address based on authentication failure in API Gateway to prevent malicious attack that occurs when a client floods a server with many requests in an attempt to interfere with server processing. This restriction prevents the malicious attack by blocking or denying the unauthenticated client from accessing the APIs, when API Gateway fails to authenticate the client. Using API Gateway, you can limit the number of times a client fails to authenticate the API in a specified time interval. The reason for authentication failure can be either of the following:

When the above mentioned authentication failure occurs, API Gateway sends the 401 or 403 error message to the client.

When API Gateway detects that the failed authentication limit has been exceeded, it blocks or denies that particular client IP address from accessing any of the APIs and sends the 403 Forbidden error to the client.

Note:

  • If an API is enforced with Identify and Access Application policy, and if the invocation fails due to non-preemptive authentication failure. API Gateway does not take such non-preemptive authentication failure into count and increase the failed authentication count.

  • When you use Load Balancer for configuring high availability between the API Gateway instances, API Gateway honours the X-Forwarded-For (XFF) header from the client. As the XFF header has the actual client IP address, API Gateway can block or deny the problematic client from accessing the protected API based on your configuration.
  • To configure restriction to IP address based on authentication

    1. Expand the menu options icon , in the title bar, and select Administration.

    2. Select Security > Global IP Access Settings.

    3. Click Authentication based restrictions - Block/Deny by IP address section and provide the following information.

      Field Description
      Enable Specifies whether restriction to IP address based on authentication is enabled. Click the toggle button to change the state to to enable IP address restriction.By default this option is disabled.
      Maximum failed authentication Specifies the maximum number of failed authentication that API Gateway can accept from a specific IP address in a given time interval.
      In (seconds) Specifies the time interval, in seconds, in which maximum authentication failure can be permitted.
      Action when limit exceeds Specifies the action to be performed when the number of failed authentication from an IP address exceeds the specified limits. Select one of the following:
      • Add IP address to deny list - Permanently denies the IP address from accessing any APIs.
      • Block the IP address - Temporarily blocks the IP address from accessing any APIs for specified time interval.
      • In (seconds). Specify the time interval for which you want to block the IP address.
      Denied IP list Specifies the list of IP addresses that are denied from access. Click in the Action column to remove an IP address from the denied list.
    4. Click Save. The configuration is saved.

    SAML Issuer

    If a native API is enforced with the SAML policy, API Gateway uses this configuration to communicate to STS (Security Token Service) to retrieve the SAML token.

    To add a SAML issuer

    1. Expand the menu options icon icon , in the title bar, and select Administration.

    2. Select Security > SAML issuer.
      The SAML issuer page lists all the issuers configured along with the Endpoint URI corresponding to each SAML issuer, if any.

    3. Click Add SAML issuer.

    4. In the Add SAML issuer section, provide the following information:

      Field Description
      Name Name of a SAML token issuer used by API Gateway.

      This value must match the value of the Issuer field in the SAML assertion.
      Normal client Selecting this sets the client that requests the SAML token.
      Act as delegation Selecting this delegates the SAML request to another user (delegator).

      The delegator uses a signature element to authenticate the SAML request.
      Issuer policy

      Specifies the name of an issuer policy to be used to communicate with SAML issuer.

      • If a value is specified for the Issuer policy field, then the selected issuer policy is applied to all APIs that are using the SAML authentication.

      • If a value is NOT specified for this field, then a default issuer policy based on the WSS Username or Kerberos communication mode is applied to all APIs.
      Communicate using. Specifies the mode of communication.
      WSS Username Specifies that WSS Username mode is used to obtain the SAML assertion to access the API. The WSS username token supplied in the header of the SOAP request that the consumer application submits to the API.
      Kerberos Specifies that Kerberos mode is used to obtain the SAML token and assertion to access the API. Transports the Kerberos token over the Transport Layer Security (TLS) protocol to provide additional security features.
      Authenticate using. Specify the type of authentication you want to use while communicating with the SAML issuer.
      For the Authentication type WSS Username, authenticate using the following:
      Custom credentials Specifies the values provided in the policy required to communicate the SAML issuer.

      Provide the following information:

      • Username. Specify a username.

      • Password. Specify a password.

      • Domain. Specify a domain.
      For the Authentication type Kerberos, authenticate using any of the following:
      Custom credentials Specifies the values provided in the policy required to communicate the SAML issuer.

      Provide the following information:

      • Client principal. A valid client LDAP user name.

      • Client password. A valid password of the client LDAP user.

      • Service principal. A valid Service Principal Name (SPN). The specified value is used by the client to obtain a service ticket from the KDC server.

      • Service principal nameform. Specifies the format in which you want to specify the principal name of the service that is registered with the principal database. Select one of the following:

        • Username. Represents the principal name as a named user defined in LDAP used for authentication to the KDC.

        • Hostbased. Represents the principal name using the service name and the host name, where host name is the host computer.
      Delegate incoming credentials Specifies the values provided in the policy required by the API providers to select whether to delegate the incoming Kerberos token or act as a normal client.

      Provide the following information:

      • Client principal. A valid client LDAP user name.

      • Client password. A valid password of the client LDAP user.

      • Service principal. A valid Service Principal Name (SPN). The specified value is used by the client to obtain a service ticket from the KDC server.

      • Service principal nameform. Specifies the format in which you want to specify the principal name of the service that is registered with the principal database. Select one of the following:

        • Username. Represents the principal name as a named user defined in LDAP used for authentication to the KDC.

        • Hostbased. Represents the principal name using the service name and the host name, where host name is the host computer.
      Incoming HTTP basic auth credentials Specifies the incoming HTTP basic authentication credentials in the transport header of the incoming request for client principal and client password.

      Provide the following information:

      • Service principal. A valid Service Principal Name (SPN). The specified value is used by the client to obtain a service ticket from the KDC server.

      • Service principal nameform. Specifies the format in which you want to specify the principal name of the service that is registered with the principal database. Available values are:

        • Username. Represents the principal name as a named user defined in LDAP used for authentication to the KDC.

        • Hostbased. Represents the principal name using the service name and the host name, where host name is the host computer.
      Endpoint URI Provide the endpoint URI of the STS.
      SAML version Specify the SAML version to be used for authentication.

      Available values are: SAML 1.1, SAML 2.0.
      WS-Trust version Specify the WS-Trust version that API Gateway must use to send the RST to the SAML issuer.

      Available values are: WS-Trust 1.0, WS-Trust 1.3.
      Applies to Specify the scope for which this security token is required.

      For example, the APIs to which this token is applied.
      Signing configurations
      Keystore alias Specify the keystore to be used by API Gateway while sending the request to the STS.

      A keystore is a repository of private keys and corresponding public certificates.
      Key alias (signing) Specify the key alias, a private key used to sign the request sent to STS.
      Encryption configurations
      Truststore alias Select the truststore that should be used by API Gateway while sending the STS request.

      Truststore is a repository that holds all the trusted public certificates.
      Certificate alias (Encryption) Select the certificate from the truststore used to encrypt the request that is sent to the STS.
      Request security token template parameters. Defines extensions to the <wst:RequestSecurityToken> element for requesting specific types of keys, algorithms, or key and algorithms, as specified by a given policy in the return token(s).
      Key Specifies the key type of the security token template.
      Value Specifies a value for the request token.

      You can add multiple key and values by clicking icon.
    5. Click Add.
      This adds the SAML issuer and it is listed in the SAML issuers list.

    Custom Assertions

    API Gateway uses WS-Security (WSS) to provide message-level security and protection for SOAP message requests from a client to an API, and SOAP message responses from an API to a client. By default, API Gateway supports the WSS policies like Username, X.509 certificate, Security Assertion Markup Language (SAML), Kerberos, Encryption, and so on, for the request or response SOAP messages, or both.

    API Gateway also provides an extension to define and use custom policy assertions. Custom assertions allow the API providers to extend and provide additional security policies that are not available by default in API Gateway.

    In WS-Security, custom assertions are used for expressing individual security requirements, constraints, or both. The individual policy assertions can be combined to create security policies that ensure secure and reliable exchanges of SOAP messages between a client and a SOAP API.

    API Gateway supports the following assertion types for enforcing a custom security policy:

    Binding Assertions

    These assertions specify the security mechanism that is to be used by the client or API such as the keys being used, algorithms, and so on. Common properties used by other assertions are also defined in the security binding assertion.

    API Gateway supports the following WS-SecurityPolicy binding assertions:

    Binding Assertion Description
    Transport Binding This assertion is used when the message is protected at the transport level. In this binding, messages are exchanged only through a defined medium, for example, HTTPS.

    Note: By default, API Gateway uses the transport binding for Kerberos authentication.
    Asymmetric Binding This assertion is used when both the initiator and the recipient possess security tokens. In this binding, initiator uses it’s private key to sign and the recipient’s public key to encrypt. Recipient uses it’s private key to decrypt and initiator’s public key to verify the signature.

    Note: By default, API Gateway uses the asymmetric binding for the security policies.
    Symmetric Binding This assertion is used when only the initiator or recipient has a security token. In this binding, both the signing and encrypting of messages is done using a single security token.

    Token Assertions

    These assertions specify the types of tokens to be used to authenticate and secure SOAP messages.

    API Gateway supports the following WS-SecurityPolicy token assertions:

    Token Assertion Description
    Username Token When using this assertion, the message-level security is implemented using a WSS username token. The assertion authenticates a client using the username and password in the SOAP request. If validation of the username token succeeds, then API Gateway passes the message to the API. If validation fails, then API Gateway returns a SOAP fault.
    X509 Token When using this assertion, the message-level security is implemented using an X.509v3 certificate. The assertion authenticates a client using the X.509v3 certificate in the SOAP request. If validation of the X.509v3 certificate succeeds, then API Gateway passes the message to the API. If validation fails, then API Gateway returns a SOAP fault.
    Kerberos Token When using this assertion, the message-level security is implemented using a Kerberos token. The assertion authenticates a client using the Kerberos token in the SOAP request. If validation of the Kerberos token succeeds, then API Gateway passes the message to the API. If validation fails, then API Gateway returns a SOAP fault.
    SAML Token When using this assertion, the message-level security is implemented using a SAML (Security Assertions Markup Language\ token. SAML is a standard data format for exchanging authentication and authorization data between the client and the SOAP API. If validation of the SAML token succeeds, then API Gateway passes the message to the API. If validation fails, then API Gateway returns a SOAP fault.

    Note: API Gateway supports both the SAML 1.1 and 2.0 standards.

    Policy Assertions

    API Gateway allows you to even define a complete custom policy assertion. For example, a policy assertion might specify a symmetric binding and the security token types that are used to digitally sign or encrypt SOAP messages between the client and API.

    Creating a Custom Assertion

    Pre-requisites:

    You must have the API Gateway’s manage security configurations functional privilege assigned to add a custom assertion.

    You might want to create a custom assertion when you want to:

    Important: When creating a custom assertion, make sure that both the syntax and the semantics of the assertion element are valid and in compliance with the Web Services Security Policy specification.

    To create a custom assertion

    1. Expand the menu options icon icon, in the title bar, and select Administration.

    2. Select Security > Custom assertions.
      API Gateway displays a list of all the currently defined policy assertions.

    3. Click Add assertion.

    4. Select the assertion type.
      The available options are:

      • Binding

      • Token

      • Policy

    5. Provide the following information:

      Field Description
      Name Name of the custom assertion. For a binding or token assertion type, this is the display name of the assertion in the Binding Assertion field or Custom Token Assertion of the Inbound Authentication - Message policy.

      For a policy assertion type, this is the display name of the assertion in the Issuer Policy field of the Add SAML Issuer configuration page.
      Select file Click Browse and select the policy assertion file to be uploaded. The Assertion element text box displays the data from the assertion file.

      If you have uploaded the policy assertion file and want to replace it, click the Delete icon.
      Assertion element If you have not uploaded the policy assertion file, provide the XML representation of assertion.
    6. Click Add. The custom assertion is added. You can create as many custom assertions you require.

    Post-requisites:

    To enforce the custom binding or token assertion in an API, select the assertion in the appropriate fields of the Inbound Authentication - Message policy:

    To enforce the custom policy assertion in an API, select the assertion and the corresponding SAML issuer in the appropriate fields:

    Viewing Custom Assertion List and Assertion Configuration

    You can view the list of configured custom assertions in API Gateway. In addition, you can view and modify the configuration in the individual custom assertion details page.

    To view a list of custom assertions and assertion configuration

    1. Expand the menu options icon icon, in the title bar, and select Administration.

    2. Select Security > Custom assertions.
      A list of all available custom assertions appears.
      You can delete a custom assertion by clicking its Delete icon.

    3. Click any custom assertion to view the configuration details.
      The custom assertion details page displays the XML element.

    Modifying Custom Assertion

    Pre-requisites:

    You must have the API Gateway’s manage security configurations functional privilege assigned to modify a policy assertion.

    You might want to modify a custom assertion to change the currently defined security settings, such as, authentication scheme, signing and encryption, algorithms and supporting tokens, of SOAP messages.

    To modify a custom assertion

    1. Expand the menu options icon icon, in the title bar, and select Administration.

    2. Select Security > Custom assertions.
      A list of all available custom assertions appears.

    3. Select the required custom assertion that you want to modify.

    4. Modify the fields as required.

    5. Click Save.
      The custom assertion is updated.

    Post-requisites:

    When you are ready to put the policy assertion into effect in an API, select it in the appropriate field of Inbound Authentication - Message policy.

    Deleting Custom Assertion

    Pre-requisites:

    You must have the API Gateway’s manage security configurations functional privilege assigned to delete a policy assertion.

    You delete a policy assertion to remove it from API Gateway permanently.

    To delete a policy assertion

    1. Expand the menu options icon icon, in the title bar, and select Administration.

    2. Select Security > Custom assertions.
      A list of all available custom assertions appears.

    3. Click icon in the action column of the custom assertion to be deleted.

    4. Click Yes in the confirmation dialog.
      The custom assertion is deleted from API Gateway.

    Example - Custom Assertions

    API Gateway, by default, uses the asymmetric binding assertion with X.509v3 token for implementing SOAP message protection. If you would like to enforce any authentication (other than the predefined authentications shipped with API Gateway), include additional WSS custom assertions, sign and encrypt SOAP messages, and define custom properties, such as the algorithms and layout of security header, you can create custom assertions that would construct the custom policy file to suit your specific security requirements.

    Following is a policy file that API Gateway generates when a WSS username token is enforced by the Inbound Authentication Message policy for an API.

    <wsp:Policy wsu:Id="9dbda2fb-9cef-4ff9-bc70-115c942a3b76"	
    	xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
    	xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
    		oasis-200401-wss-wssecurity-utility-1.0.xsd">
    	<wsp:ExactlyOne>
    		<wsp:All>
    (L01) <sp:AsymmetricBinding xmlns:sp=
    	"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
    	xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
    	<wsp:Policy>
    		<sp:InitiatorToken>
    			<wsp:Policy>
    				<sp:X509Token sp:IncludeToken
    				"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702
    															/IncludeToken/Never">
    	<wsp:Policy>
    				<sp:WssX509V3Token10 />
    			</wsp:Policy>
    		</sp:X509Token>
    	</wsp:Policy>
    	</sp:InitiatorToken>
    	<sp:RecipientToken>
    		<wsp:Policy>
    			<sp:X509Token sp:IncludeToken=
    				"http://docs.oasis-open.org/ws-sx/ws-securitypolicy
    				/200702/IncludeToken/Never">
    		<wsp:Policy>
    			<sp:WssX509V3Token10 />
    		</wsp:Policy>
    			</sp:X509Token>
    				</wsp:Policy>
    					</sp:RecipientToken>
    					<sp:AlgorithmSuite>
    						<wsp:Policy>
    							<sp:TripleDesRsa15 />
    						</wsp:Policy>
    					</sp:AlgorithmSuite>
    	<sp:Layout>
    		<wsp:Policy>
    		<sp:Strict />
    		</wsp:Policy>
    	</sp:Layout>
    		<sp:ProtectTokens/>
    		</wsp:Policy>
    		</sp:AsymmetricBinding>
    		<sp:SupportingTokens xmlns:sp=
    			"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
    		<wsp:Policy>
    			<sp:UsernameToken sp:IncludeToken=
    			"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/
    				IncludeToken/AlwaysToRecipient"/>
    				</wsp:Policy>
    					</sp:SupportingTokens>
    				</wsp:All>
    			</wsp:ExactlyOne>
    	</wsp:Policy>

    You might have a requirement to change the policy assertion that is available by default in API Gateway. For example, you might want to generate the above security policy using a symmetric binding instead of the default asymmetric binding, and modify the username token that is defined by default as a supporting token to a signed supporting token. You could then create custom policy assertions to achieve these specific requirements.

    Important: When adding a custom policy assertion, make sure that both the syntax and the semantics of the assertion are valid and in compliance with the Web Services Security Policy specification.

    Symmetric Binding Assertion

    You might want to use a symmetric binding (instead of the default asymmetric binding) when only API Gateway possess the X.509v3 token for authentication. You might also want to sign and encrypt the SOAP messages, modify the encryption algorithm, and include timestamp on the SOAP messages. You would then create a custom binding assertion with the specific property lines:

    	
    <sp:SymmetricBinding
    xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
    xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
    <wsp:Policy>
    <sp:ProtectionToken>
    <wsp:Policy>
    <sp:X509Token sp:IncludeToken=
    	"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/
    	IncludeToken/AlwaysToRecipient">
    	<wsp:Policy>
    	<sp:WssX509V3Token10/>
    	<sp:WssX509PkiPathV1Token10/>
    	</wsp:Policy>
    	</sp:X509Token>
    	</wsp:Policy>
    	</sp:ProtectionToken>
    	<sp:AlgorithmSuite>
    	<wsp:Policy>
    	<sp:TripleDesRsa15/>
    	</wsp:Policy>
    	</sp:AlgorithmSuite>
    	<sp:Layout>
    	<wsp:Policy>
    	<sp:Strict/>
    	</wsp:Policy>
    	</sp:Layout>
    	<sp:IncludeTimestamp/>
    	<sp:ProtectTokens/>
    	<sp:OnlySignEntireHeadersAndBody/>
    	<sp:SignBeforeEncrypting/>
    	</wsp:Policy>
    	</sp:SymmetricBinding>
    	

    You could create custom assertions to include one or more of the following security requirements:

    Supporting Token Assertions

    You might want to sign the supporting token for example, WSS username token, and use SignedSupportingTokens assertion. You might also want to specify that the signed username token must always be included in the messages sent to the recipient. You would then create a custom token assertion with the specific property lines:

    	
    <sp:SignedSupportingTokens xmlns:sp=
    	"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
    	<wsp:Policy>
    		<sp:UsernameToken sp:IncludeToken=
    				"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/
    											IncludeToken/AlwaysToRecipient"/>
    			</wsp:Policy>
    		</sp:SignedSupportingTokens>
    	

    WSS Token Assertions

    You might want to include WSS10 and WSS11 assertions to provide additional SOAP message security. You would then create two separate custom token assertions with the specific property lines:

    Wss10 assertion:

    <sp:Wss10
    		xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
    		xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
    	<wsp:Policy>
    		<sp:MustSupportRefIssuerSerial/>
    	</wsp:Policy>
    </sp:Wss10>
    	

    Wss11 assertion:

    	
    <sp:Wss11
    	xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
    	xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
    	<wsp:Policy>
    		<sp:MustSupportRefIssuerSerial/>
    		<sp:MustSupportRefThumbprint/>
    		<sp:RequireSignatureConfirmation/>
    	</wsp:Policy>
    </sp:Wss11>
    	

    After you have defined these custom assertions in API Gateway, execution of a policy that is configured with all of these custom assertions in the Inbound Authentication - Message policy, would construct the custom security policy file as follows:

    	
    <wsp:Policy wsu:Id="1e747a18-b55d-4e99-ac67-80a8eafd76b3"
    	xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
    	xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
    				oasis-200401-wss-wssecurity-utility-1.0.xsd">
    <wsp:ExactlyOne>
    	<wsp:All>
    		<sp:SymmetricBinding xmlns:sp=
    	"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
    		<wsp:Policy>
    			<sp:ProtectionToken>
    		<wsp:Policy>
    		<sp:X509Token sp:IncludeToken=
    		"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/
    			IncludeToken/AlwaysToRecipient">
    					<wsp:Policy>
    						<sp:WssX509PkiPathV1Token10/>
    					</wsp:Policy>
    		</sp:X509Token>
    		</wsp:Policy>
    	</sp:ProtectionToken>
    	<sp:AlgorithmSuite>
    				<wsp:Policy>
    					<sp:TripleDesRsa15/>
    				</wsp:Policy>
    	</sp:AlgorithmSuite>
    	<sp:Layout>
    	<wsp:Policy>
    			<sp:Strict/>
    	</wsp:Policy>
    	</sp:Layout>
    	<sp:OnlySignEntireHeadersAndBody/>
    	</wsp:Policy>
    	</sp:SymmetricBinding>
    	<sp:SignedSupportingTokens xmlns:sp=
    				"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
    				<wsp:Policy>
    					<sp:UsernameToken sp:IncludeToken=
    					"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/
    					IncludeToken/AlwaysToRecipient"/>
    				</wsp:Policy>
    	</sp:SignedSupportingTokens>
    				<sp:Wss11 xmlns:sp=
    				"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
    				<wsp:Policy>
    				<sp:MustSupportRefIssuerSerial/>
    				<sp:MustSupportRefThumbprint/>
    				<sp:RequireSignatureConfirmation/>
    	</wsp:Policy>
    	</sp:Wss11>
    				<sp:Wss10 xmlns:sp=
    						"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
    					<wsp:Policy>
    					<sp:MustSupportRefIssuerSerial/>
    					</wsp:Policy>
    				</sp:Wss10>
    				<sp:EncryptedParts xmlns:sp
    					"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
    					<sp:Body/>	
    				</sp:EncryptedParts>
    		</wsp:All>
    	</wsp:ExactlyOne>
    </wsp:Policy>

    Kerberos Settings

    Kerberos is an authentication protocol that uses symmetric encryption and a trusted third party system to validate the identity of clients. The Kerberos protocol provides authentication over open and insecure networks in which communication between the hosts can be intercepted.

    You can use API Gateway to configure Kerberos authentication for API requests. API Gateway provides support for using Kerberos authentication for inbound and outbound HTTP and HTTPs requests at the transport and the message level.

    Kerberos authentication system consists of the a Kerberos client that needs to access and use Kerberos services, a trusted third-party system, specifically a Key Distribution Center (KDC) and a server that hosts APIs that are accessible using Kerberos authentication.

    Configuring API Gateway to Use Kerberos

    Before you configure API Gateway to use Kerberos authentication, ensure that:

    To configure API Gateway to use Kerberos

    1. Expand the menu options icon icon , in the title bar, and select Administration.

    2. Select Security > Kerberos.

    3. Click Edit.

    4. Provide or modify the following information as required:

      Field Description
      Realm Optional. The domain name of the Kerberos server, in uppercase letters.

      Note: A value specified for Realm overwrites the realm set in the KDC configuration file specified in Kerberos configuration file.
      Key distribution center Optional. The host name of the machine on which the KDC resides.

      A value specified for Key distribution center overwrites the default key distribution center set in the KDC configuration file specified in Configuration file.
      Configuration file The location of the Kerberos configuration file that contains the Kerberos configuration information, including the locations of KDCs, defaults for the realm and for Kerberos applications, and the host names and Kerberos realms mappings.
      Use subject credentials Specifies whether API Gateway requires a Kerberos V5 Generic Security Services (GSS) mechanism to obtain the necessary credentials from an existing subject set up by the JAAS authentication module. Here, subject represents the user or service being authenticated in the JAAS login context.
    5. Click OK.

    OAuth, JWT, and OpenID Configuration

    This section describes the Open Authorization (OAuth), JSON Web Token (JWT), and OpenID Connect (OpenID) authentication protocols that you can use to identify and authorize a client application. The application is first identified based on the criteria provided in the strategy configured. A strategy is a way to authenticate the incoming request and provides multiple authentication mechanisms or multiple authorization servers for a single authentication scheme. API Gateway identifies the application and validates the token submitted through the strategy configured in the application.

    Configuring the Internal Authorization Server

    Pre-requisites:

    You must have the API Gateway’s manage security configurations functional privilege assigned to add an authorization server.

    You have to configure API Gateway with the required information to act as an internal authorization server for OAuth or JWT depending on what authentication protocol you want to use to identify and authorize a client application. You can also define the required scopes that provide a way to limit the amount of access that is granted to an access token.

    To configure an internal authorization server

    1. Expand the menu options icon icon, in the title bar, and select Administration.

    2. Select Security > OAuth/JWT/OpenID.

    3. In the Internal Authorization servers section, click local. This is the internal authorization server available that you can configure with required information to act as an internal authorization server for OAuth, JWT or OpenID authentication protocols.

    4. The name field is pre-populated with the name of the internal authorization server, local, which is non-editable.

    5. The description for the internal authorization server is pre-populated with the description available. You can modify the description as required.

    6. Click JWT configuration to configure API Gateway as a JWT issuer. Alternatively you can expand or collapse a section, using the down arrow icon and the up arrow icon and that appear next to the section name.

    7. Provide the following information as required:

      Field Description
      Token issuer Name of the JWT token issuer used by API Gateway.

      Note: The Token issuer value is case-sensitive.
      Algorithm The cryptographic algorithm to sign JSON Web Tokens (JWTs).

      Supported values are: RS256, RS384, and RS512.
      Expiry duration The duration (in minutes) for which the token is valid.

      For example, the value 60 denotes that the access token will expire in one hour from the time the token was generated.
      Audience Optional. The intended recipient of the token. The application that receives the token must verify that the audience value is correct and reject any tokens intended for a different audience.
      Keystore alias Alias of the keystore containing the private key that is used to sign JWTs.

      The Keystore alias field contains a list of the available keystore aliases in API Gateway. If there are no configured keystore aliases, this field displays the DEFAULT_IS_KEYSTORE.
      Key alias Alias of the private key used to sign JWTs.

      The Key alias field contains a list of the available aliases in the selected keystore. If there are no configured keystores, this field is empty.
    8. Click OAuth configuration to configure API Gateway as an OAuth authorization server. Alternatively you can expand or collapse a section, using the down arrow icon and the up arrow icon and that appear next to the section name.

    9. Provide the following information as required:

      • Authorization code expiration interval. Specifies the time (in seconds) during which the authorization code issued by the authorization server is valid. Valid values are between 1 and 2147483647. The default value is 600.

      • Access token expiration interval. Specifies the time (in seconds) for which the access tokens issued by the authorization server are valid. The default value is 3600. Value of -1 specifies that the access token does not expire.

    10. Click OAuth tokens.

      This lists the available OAuth tokens with the following details:

      • Client ID. Specifies the ID of the client application that requested the access token.

      • Owner ID. Specifies the ID of the owner who issues the access token.

      • Access token. Specifies the access token.

      • Refresh token. You can use to generate a new access token if the existing access token is expired.

      • Remaining refresh limit. Displays the remaining attempts for refreshing the access token.

      • Action. Revokes the access tokens, which means those tokens cannot be used to invoke the protected resource. For information about revoking access token using REST API, see Revoking OAuth Tokens.

      Note By default, API Gateway lists only 5 records and provides pagination to explore more tokens. You can also use the search and filter options to find the OAuth tokens.

    11. Click OAuth scopes.
      OAuth 2.0 scopes provide a way to limit the amount of access that is granted to an access token. For example, an access token issued to a client application may be granted READ and WRITE access to the protected resources, or just the READ access. You can implement your APIs to enforce any scope or a combination of scopes as required. So, if a client receives a token that has READ scope, and it tries to invoke an API endpoint that requires WRITE access, the invocation fails.

      You can provide the meaning to the scope in OAuth/OpenID scopes management section.

    12. Type the scope that is registered in the authorization server and click +Add.
      You can include multiple scopes.

    13. Click Update.
      This updates the internal authorization server details with the required information and is listed in the table of Internal authorization server.

    Adding a Provider

    Pre-requisites:

    You must have the API Gateway’s manage security configurations functional privilege assigned to add a provider.

    The OAuth 2.0 configuration in API Gateway is split into two sections - Providers and Authorization servers.

    You have to add a provider and configure the authorization provider metadata information in this section for API Gateway to communicate with this provider during dynamic client registration only. If there is any deviation from the actual OAuth specification then the provider has to be configured for these deviations.

    To add a provider

    1. Expand the menu options icon icon, in the title bar, and select Administration.

    2. Select Security > JWT/OAuth/OpenID > Providers.

    3. Click Add provider and provide the following information:

      Field Description
      Name Name of a third-party provider. For example, Amazon.

      You can also use one of the following pre-configured third-party providers that is shipped with the API Gateway installation:

      • PingFederate

      • OKTA
      Client metadata field mapping. Specifies the mapping of dynamic client registration specification to that of the client implementation of the provider.

      The Client metadata field mapping fields are required when you are adding a third-party provider that is not shipped with API Gateway.
      Specification name The client metadata attributes in accordance with the dynamic client registration specification as defined in RFC 7591. The available values are:

      • redirect_uris. Redirection URL that the authorization server uses to redirect the authorization code once the authorization request is approved by end user.
        Note: If you do not specify this attribute, API Gateway automatically generates the URL.

      • token_endpoint_auth_method. The client authentication method at the token endpoint.

      • grant_types. The grant type of authorization flow to obtain authorization codes, ID tokens, and refresh tokens.

      • application_type

      • response_types. The type of response that the client application uses at the authorization endpoint.

      • client_name. Name of the client to use to represent the client application to the end user during authorization.

      • client_uri. URL of the client application.

      • logo_uri. URL of an image to use to represent the client application to the end user during authorization.
        Note: The logo_uri is currently not supported in API Gateway.

      • scope. List of user-authorized scopes that the client uses for requesting access tokens.
        Note: If you do not specify this attribute, the authorization server registers the client with a default set of scopes.

      • contacts. The means (for example, Email address) by which end users can contact the client for support requests.

      • tos_uri. URL of the service document for the client that describes a contractual relationship between the end-user and the client that the end-user accepts when authorizing the client.
        Note: The tos_uri is currently not supported in API Gateway.

      • jwks_uri. URL of the JSON Web Key (JWK) Set document containing the client’s public keys.
        Note: The jwks_uri is currently not supported in API Gateway.

      • client_id. Identifier that is unique to the client application.

      • client_secret. The password or phrase for the client application to use to authorize communication with the end user.
      Implementation name The client metadata attributes that are used by the authorization server, but are not in accordance with the dynamic client registration specification.

      Example:

      • For the redirect_uris field, provide the value redirectUris.

      • For the grant_types field, provide the value grantTypes.

      • For the client_name field, provide the value name.

      • For the logo_uri field, provide the value logoUrl.

      • For the client_id field, provide the value clientId.

      • For the client_secret field, provide the value secret.
      Extended request parameters. Specifies the additional client metadata attributes that are specific to the authorization server, and are not specified in the dynamic client registration specification.

      In PingFederate (For example): forceSecretChange = true
      Type Specifies the client metadata attribute type. The available values are: Client read, Client registration, Client update, Client delete.
      Key The client metadata attribute key that is specific to the authorization server.
      Value A value for the client metadata attribute key. When sending requests to the authorization server, this value is appended to all requests.
      You can add multiple request parameters by clicking + Add.
      Application profile Specifies the application profile that is specific to the authorization server.
      Type Specifies custom application type other than web and native.
      By default, the web and native application is added.
      You can add multiple application type by clicking + Add. You can also modify and delete the added application type by clicking the respective Edit or Delete icon.
      You can add multiple request parameters by clicking + Add.

    4. Click Save.
      The provider is added and displayed in the list of providers.

    Adding an External Authorization Server

    Pre-requisites:

    You must have the API Gateway’s manage security configurations functional privilege assigned to add an authorization server.

    As an alternative to using API Gateway as the authorization server, you can use a third-party server as the authorization server. To use an external authorization server, you must configure your third-party authorization server.

    To add an external authorization server

    1. Expand the menu options icon icon, in the title bar, and select Administration.

    2. Select Security > OAuth/JWT/OpenID.
      The available and configured internal authorization servers and external authorization servers are listed in the respective sections.

    3. Click Add authorization server in the External authorization servers section.

    4. Type a name for the external authorization server.

    5. Type a description for the external authorization server that is being configured.

    6. Provide the discovery endpoint in the Discovery URL field and click Discover.
      When you specify the discovery URL, API Gateway fetches data from the URL response and auto-populates the fields with the fetched data.

    7. Click Introspection and provide the following information to validate the incoming tokens.

      Field Description
      Local introspection. Provide the following information to validate the tokens locally.
      Issuer Name of the token issuer.
      JWKS URI Specifies JSON Web Key Signature endpoint to retrieve the corresponding public certificates for performing local introspection.
      After an API Gateway node restarts, when there is an authorization request with a JWT token claim kid, the required certificates for the claim are retrieved and stored in cache. For the subsequent requests with the same claim, the local introspection is performed from the certificates in the cache instead of retrieving the certificates afresh until API Gateway restarts.
      Truststore alias Specify the alias of the truststore on API Gateway that holds the Certificate Authority (CA) certificate of third-party authorization server.

      This is required if the JWKS URI is not available for the authorization server and you want to configure this certificate directly.
      Certificate alias Alias of the certificate used to validate the token.

      The Certificate alias field contains a list of the available aliases in the selected truststore. If there are no configured truststores, this field is empty.
      Remote introspection. Provide the following information to validate the tokens remotely if local introspection cannot be done.
      Introspection endpoint URL of the token introspection endpoint of a third-party OAuth 2.0 authorization server. API Gateway uses the introspection endpoint to check that access tokens used in client requests are currently active and are valid to invoke the protected resources.
      Gateway user The name of the Gateway user that API Gateway uses to invoke the token introspection endpoint.
      Client ID ID of the introspection client on the authorization server that API Gateway uses to introspect the access tokens.
      Client secret Password of the introspection client that API Gateway uses to introspect the access tokens.
    8. In the Dynamic client registration section, provide the following information if you want to dynamically create a client from API Gateway when required. You would use this configuration only if you do not intend to use any of the existing clients.

      Field Description
      Enabled Specifies whether dynamic client registration is enabled.

      Click the toggle button to change the state to icon to enable dynamic client registration.

      By default this option is disabled.
      Provider name Select the name of the third-party provider.
      Client registration URL Specifies the corresponding REST endpoint URLs for the client configuration of REST APIs.
      Authentication type Specifies the type of authentication scheme that API Gateway would use to communicate with the external authorization server for client management.

      Select one of the following authentication type:

      • Basic. Specifies the username and password information that would be passed in the authorization header of HTTP request for client authentication.

        • Username. The username to access the protected resources of REST APIs.

        • Password. A valid password associated with the username.

      • Token. Specifies the token information that would be added as a bearer token in the HTTP request for client authentication.

        • Token type. The type of token that would be contained in the HTTP request.

        • Token. The token that would be contained in the HTTP requests.
      • Refresh Token.The refresh token that you would get from the external authorization server for the registered client ID and client secret.

        • Client ID. The client ID that you want to specify from the external authorization server.

        • Client secret. A valid client secret associated with the client ID.
      • Client Credentials.Specifies the client information for which the application is created in the external authorization server.

        • Scope. The scope of the client application that you want to specify from the external authorization server.

        • Client ID. The client ID that you want to specify from the external authorization server.

        • Client secret. A valid client secret associated with the client ID.
      • None.Specifies that you could create the client dynamically in the external authorization server without using any type of authorization.
      Supported grant types Specifies the list of grant types that are supported by API Gateway.Basically, grant types are the ways to get an access token from the external authorization server. Provide the grant type, in the Supported grant types field and click +Add.You can add more than one grant by clicking +Add.
    9. In the SSL Configuration section, provide the following information for SSL configuration, if the authorization server wants the 2-way SSL for the requests.

      Field Description
      Keystore alias Alias of the keystore containing the private key that is used for a secured communication between API Gateway and the authorization server.

      You can view all the keystore aliases available in API Gateway. If there are no configured keystore aliases, the list box contains only the default keystore, DEFAULT_IS_KEYSTORE.
      Key alias Alias for the private key to use to validate the HTTP requests from the client.

      You can view all the aliases available in the selected keystore. If there are no configured keystores, this list box is empty.
      Truststore alias Alias of the truststore on API Gateway that holds the Certificate Authority (CA) certificate of third-party authorization server.

      Note: You need to select a truststore alias only when all of the following are true:

      • The client account on the third-party authorization server is configured to use mutual (two-way) SSL, and

      • The authorization server’s Certificate Authority certificate is not in the set of well-known authorities trusted by the JVM in which API Gateway runs.
    10. In the Metadata section, provide the following information for the authorization server metadata, which is used for the communication to portal.

      Field Description
      Access token URL The endpoint URL on the authorization server through which the client application exchanges the authorization code, client ID, and client secret, for an access token.
      Authorize URL The endpoint URL on the authorization server through which the end user authenticates and grants authorization to the client application.
      Refresh token URL The endpoint URL on the authorization server through which the client application refreshes an expired access token.
    11. Click Scopes.
      OAuth 2.0 scopes provide a way to limit the amount of access that is granted to an access token. For example, an access token issued to a client application may be granted READ and WRITE access to the protected resources, or just the READ access. You can implement your APIs to enforce any scope or a combination of scopes as required. So, if a client receives a token that has READ scope, and it tries to invoke an API endpoint that requires WRITE access, the invocation fails.

      You can provide the meaning to the scope in OAuth/OpenID scopes management section.

    12. Provide the scope, in the Scope field that is registered in the authorization server and click +Add.
      You can add more than one scope by clicking +Add.

    13. Click Save. The external authorization server is added.
      You can add as many authorization servers as required, but only one is the default at any given time.

    Mapping OAuth or OpenID Scopes

    You must have the API Gateway’s manage security configurations functional privilege assigned to manage scopes.

    You have to map the scope that you have defined in the authorization server with the APIs in API Gateway to authorize the access tokens to be used to access the protected resources. You can map either a complete API or parts (resources or methods) of an API to the scope.

    For example, if there is a scope you have defined for an external authorization server, such as readonly, then the access tokens which contain readonly as their scope, should access only the GET resources. So, you can create an API Scope for the GET resources in an API or for multiple APIs and then map this readonly scope to all those API Scopes. Now this access token can invoke only the GET resources. If it tries to invoke any POST or PUT resource it fails. As another example you can consider mapping a business scope such as, inventory, that you have defined in the authorization server; you can map all the resources required for the inventory business to this scope.

    To map a scope

    1. Expand the menu options icon icon, in the title bar, and select OAuth/OpenID scopes.

    2. Click Map scope.

    3. Provide the following information in the Authorization server scope section:

      Field Description
      Select authorization server scope Specifies the scope linked to the authorization server. Type a search word and select the required scope from the search list populated.
      Name Displays the name of the authorization server scope selected. This is populated by default and is non-editable.
      Description A brief description for the scope being mapped.
      Audience Provide a value or URI, the intended recipient of the authorization server scope. The application that receives the token verifies that the audience value is correct and rejects any tokens intended for a different audience.
    4. Click API scopes.

    5. Specify an API scope that is to be linked to the authorization server.
      Alternatively, you can type a search word and select the required API scope from the search list populated.
      The API scopes added are listed in the Selected API scopes table. You can click the delete icon icon, in the corresponding column, to delete an API scope from the list.

    6. Click Save.

    This maps the authorization server scope to the selected API scopes and lists the authorization scope in the scopes list.

    Viewing Scope Mapping Details

    You must have the API Gateway’s manage security configurations functional privilege assigned to manage scopes.

    You can view the scope details and modify the scope details as required from the OAuth/OpenID scopes page.

    To view scope mapping details

    1. Expand the menu options icon icon, in the title bar, and select OAuth/OpenID scopes.
      A list of available scopes appears. Use the Show drop-down list at the bottom of the page to set the maximum number of scopes you want to display in a page. The details, such as, name and description of the scope is displayed in the form of a table. You can delete a scope by clicking the delete icon icon.

    2. Click a scope.
      The scope details page appears. This page displays the details such as the authorization server name, the server scope, the API scopes that are linked to the server scope and the API scope details such as the API to which the scope is associated, the description of the API and API version number.

      You can modify the scope by clicking the Edit button and modifying the required values.

    Viewing Provider List and Provider Configuration

    You can view the list of integrated third-party providers and their configuration details, modify the provider configuration, and delete a provider in the Providers section.

    To view a list of providers and provider configuration

    1. Expand the menu options icon icon, in the title bar, and select Administration.

    2. Select Security > JWT/OAuth/OpenID > Providers.
      The Providers section displays a list of all the defined third-party providers in API Gateway.

      You can also perform the following operations in the Authorization servers section:

      • You can view the configuration details of the provider by clicking the required provider. The provider details page displays the client metadata field mapping and extended request parameter configuration information of the selected provider.

      • You can edit the provider configuration by clicking the required authorization server and modifying the details as required.

      • You can reset the configuration to system default value by clicking icon in the Action column for the respective provider.

      • You can delete the required authorization server by clicking icon in the Action column for the respective provider.

    Modifying the Provider Configuration

    Pre-requisites:

    You must have the API Gateway’s manage security configurations functional privilege assigned to modify a provider.

    You might want to modify a provider to change the currently defined configuration settings.

    To modify a provider configuration

    1. Expand the menu options icon icon, in the title bar, and select Administration.

    2. Select Security > JWT/OAuth/OpenID > Providers.
      The Providers section displays a list of all the available providers in API Gateway.

    3. Click the name of the partner provider you want to modify.

    4. Modify the fields as required.

    5. Click Save.
      The provider is updated.

    Viewing Authorization Server List and Server Configuration

    You can view the list of authorization servers and their configurations details, modify the server configuration, and delete an authorization server in the Authorization servers section.

    To view a list of authorization servers and server configuration

    1. Expand the menu options icon icon, in the title bar, and select Administration.

    2. Select Security > JWT/OAuth/OpenID.
      The Authorization servers section displays a list of all the internal and external authorization servers in API Gateway under respective sections.

      You can also perform the following operations in the Authorization servers section:

      • You can view the configuration details of the authorization server by clicking the required authorization server. The authorization server details page displays the client information, scope information, and token information of the selected authorization server.

      • You can edit the server configuration by clicking the required authorization server and modifying the details as required.

      • You can delete the required authorization server by clicking icon in the Action column for the respective authorization server.

    Modifying Authorization Server Configuration

    Pre-requisites:

    You must have the API Gateway’s manage security configurations functional privilege assigned to modify an authorization server.

    You might want to modify an OAuth 2.0 authorization server to change the currently defined configuration settings.

    To modify the authorization server configuration

    1. Expand the menu options icon icon, in the title bar, and select Administration.

    2. Select Security > JWT/OAuth/OpenID.
      The Authorization servers section displays a list of all the internal and external authorization servers in API Gateway.

    3. Click the name of the authorization server you want to modify.

    4. Modify the fields as required.

    5. Click Save.
      The authorization server is updated.

    Deleting an Authorization Server

    Pre-requisites:

    You must have the API Gateway’s manage security configurations functional privilege assigned to delete an authorization server.

    You delete an authorization server to remove it from API Gateway permanently.

    To delete an authorization server

    1. Expand the menu options icon icon, in the title bar, and select Administration.

    2. Select Security > JWT/OAuth/OpenID.
      The Authorization servers section displays a list of available internal and external authorization servers in API Gateway.

    3. Click icon in the action column of the authorization server to be deleted.

    4. Click Yes in the confirmation dialog.
      The authorization server is deleted from API Gateway.

    Deleting a Provider

    Pre-requisites:

    You must have the API Gateway’s manage security configurations functional privilege assigned to delete a provider.

    You delete a provider to remove it from API Gateway permanently.

    Important: You must not delete a provider if it is being used by an authorization server.

    To delete a provider

    1. Expand the menu options icon icon, in the title bar, and select Administration.

    2. Select Security > JWT/OAuth/OpenID.
      The Providers section displays a list of available providers in API Gateway.

    3. Click icon in the Action column of the provider to be deleted.

    4. Click Yes in the confirmation dialog.
      The provider is deleted from API Gateway.

    Configuring Communication Details for Microgateway

    When you want Microgateway to use API Gateway as an OAuth2 authorization server, the communication channel between Microgateway and API Gateway has to be set up. The access token is then introspected in the Microgateway using remote introspection. To enable this you have to configure communication details, such as the introspection endpoint, client ID and client secret, in API Gateway, which are then used by Microgateway to introspect the tokens in API Gateway.

    To configure the communication details for Microgateway

    1. Expand the menu options icon icon, in the title bar, and select Administration.

    2. Select Security > JWT/OAuth/OpenID > Microgateway.

    3. In the Introspection endpoint field, provide the URL of the introspection endpoint.
      For example: http&colon;//localhost:5555/invoke/pub.oauth/introspectToken. The endpoint can have http or https depending on the protocol used and the hostname and port are the details of the host used.

      Microgateway uses the introspection endpoint to check that access tokens used in client requests are currently active and are valid to invoke the protected resources.

    4. In the Client ID field, provide an ID, which specifies the ID of the introspection client on the authorization server that Microgateway uses to introspect the access tokens.

    5. In the Client secret field, provide the Client secret, which specifies the password of the introspection client that Microgateway uses to introspect the access tokens.

    6. In the JWKS URI field, provide the JSON Web Key Signature endpoint to retrieve the corresponding public certificates for performing local introspection.

      After Microgateway node restarts, when there is an authorization request with a JWT token claim kid, the required certificates for the claim are retrieved and stored in cache. For the subsequent requests with the same claim, the local introspection is performed from the certificates in the cache instead of retrieving the certificates afresh until Microgateway restarts.

    7. Click Save.

      The information provided here is stored in the configuration properties file and provisioned as part of the asset provisioning during Microgateway startup.

    Removing Expired OAuth Tokens

    You can remove all the expired OAuth access tokens using the given API.

    You can also schedule the cleanup of the expired OAuth access tokens as required.

    To remove expired OAuth tokens

    1. Make a REST call to the following endpoint:

      GET hostname:port/invoke/pub.oauth/removeExpiredAccessTokens

    Revoking OAuth Tokens

    You can revoke the OAuth access token from an application using the given API.

    To revoke OAuth token from an application

    1. Make a REST call to the following endpoint with the corresponding client Id and secret of the application in Basic authentication header:

      POST hostname:port/invoke/pub.oauth/revokeToken

      Sample request

      POST http(s)://hostname:port/invoke/pub.oauth/revokeToken
      { "token":"3d77988d5020493c8edde78b12c347e2046ac8438a91405597e669ed714ba96a",
      "token_type_hint":"accessToken"}

    Managing Threat Protection Policies

    Threat protection policies prevent malicious attacks from client applications that typically involve large, recursive payloads, and SQL injections. You can limit the size of things, such as maximum message size, maximum number of requests, and maximum node depth and text node length, in the XML document. You can configure the global threat protection policies and rules for all the incoming requests that comes through the external port of API Gateway. These policies and rules are enforced by API Gateway based on your configuration.

    You must have the API Gateway’s manage threat protection functional privilege to configure the following policies and rules.

    In addition, the API Gateway administrator can configure the necessary mobile devices and applications for which you want to deny the access, configure and customize the deny and alert rules, and manage the denied IPs.

    Basically, when you configure the threat protection policy in a clustered setup, you specify the limitations (such as number of requests and concurrent request) that an API Gateway instance in the cluster can handle during a specified time interval. Hence, if you add X number of API Gateway instances, the limitations set in the configuration also increases by X times.

    For example, if you have two API Gateway instances and set the limitations as 100 requests per minute, then the API Gateway instances should be able to handle 200 requests per minute. When you add one more API Gateway instance, the processing capacity also increases to 300 requests per minute. Here, the API Gateway cluster used for Threat Protection does not act as a single unit.

    Note: When you have configured a load balancer, the load balancer exposes the actual client IP address using the X-Forwarded-For (XFF) headers. The watt.server.enterprisegateway.ignoreXForwardedForHeaderproperty specifies whether API Gateway uses or ignores the IP address in the XFF headers. By default, API Gateway ignores the client IP address and so the watt.server.enterprisegateway.ignoreXForwardedForHeader property is set to true. If you want API Gateway to use the actual client IP address present in the XFF, then set the watt.server.enterprisegateway.ignoreXForwardedForHeader property to false.

    Configuring Global Denial of Service Policy

    You can configure this policy in API Gateway to prevent Denial of Service (DoS) attacks. One form of DoS attack occurs when a client floods a server with many requests in an attempt to interfere with server processing. Using API Gateway, you can limit the number of requests that API Gateway accepts within a specified time interval and the number of requests that it can process concurrently. By specifying these limits, you can protect API Gateway from DoS attacks.

    You can configure API Gateway to limit the total number of incoming requests from the external ports. For example, you might want to limit the total number of requests received to 1000 requests in 10 seconds, and limit the number of concurrent requests to 100 requests in 10 seconds. When API Gateway detects that a limit has been exceeded, it blocks the exceeding requests for a specific time interval and displays an error message to the client based on your configuration. You can also configure a list of trusted IP addresses so that the requests from these IP addresses are always allowed and not blocked.

    To configure global denial of service policy

    To configure global denial of service policy

    1. Click Policies in the title navigation bar.

    2. Select Threat protection > Global denial of service.

    3. Set the Enable button to the On position to enable the policy.

    4. Type the maximum number of requests, in the Maximum requests field, that API Gateway can accept from any IP address in a given time interval.

    5. Specify time in seconds, in the In (seconds) field, in which the maximum requests have to be processed.

    6. Type the maximum number of concurrent requests, in the Maximum requests in progress field, that API Gateway can process concurrently.

    7. Specify the time in minutes, in the Block intervals (minutes) field, for which you want requests to be blocked.

    8. Type the alert message text, in the Error message field, to be displayed when the policy is breached.

    9. Add IP addresses, in the Trusted IP addresses field, that can be trusted and are always allowed.

      • API Gateway supports IPv4 and IPv6 addresses in the trusted IP addresses lists.

      • You can specify a range of IP addresses using the classless inter-domain routing (CIDR) notation. To specify an IP address range, type the first IP address in the range followed by a forward slash (/) and a CIDR suffix.

        Example IPv4 address range:

        • 192.168.100.0/22 represents the IPv4 addresses from 192.168.100.0 to 192.168.103.255
        • 148.20.57.0/30 represents the IPv4 addresses from 148.20.57.0 to 148.20.57.3

        Example IPv6 address range:

        • f000::/1 represents the IPv6 addresses from f000:: to ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff.
        • 2001:db8::/48 represents the IPv6 addresses from 2001:db8:0:0:0:0:0:0 to 2001:db8:0:ffff:ffff:ffff:ffff:ffff.

      Click icon to add more than one IP address.

    10. Click Save.

    Configuring Denial of Service by IP Policy

    You can configure this policy in API Gateway to prevent Denial of Service (DoS) attacks. One form of DoS attack occurs when a particular client floods a server with many requests in an attempt to interfere with server processing and not letting other clients in accessing the server. Using Denial of Service (DoS) by IP policy, you can limit the number of requests that API Gateway accepts from a particular IP address within a specified time interval and the number of requests that it can process concurrently from any IP address. By specifying these limits, you can protect API Gateway from DoS attacks by a particular IP address. When API Gateway detects that a limit has been exceeded, it blocks or denies the requests from that particular IP address and displays an error message to the client based on your configuration. You can also configure a list of trusted IP addresses so that the requests from these IP addresses are always allowed and not denied.

    Note: To configure the denial of service by IP policy, you have to set watt.server.enterprisegateway.ignoreXForwardedForHeader property to false. When this setting is configured, the incoming request header will have the XFF header and tracks actual client IP address, which in turn allows you to configure DoS by IP.

    To configure the denial of service by IP policy

    1. Click Policies in the title navigation bar.

    2. Select Threat protection > Denial of service by IP.

    3. Set the Enable button to the On position to enable the policy.

    4. Type the maximum number of requests, in the Maximum requests field, that API Gateway can accept from a specific IP address in a given time interval.

    5. Specify time in seconds, in the In (seconds) field, in which the maximum requests have to be processed.

    6. Type the maximum number of requests, in the Maximum requests in progress field, that API Gateway can process concurrently from any single IP address.

    7. Select one of the following actions to be taken when the number of requests from a non-trusted IP address exceeds the specified limits:

      • Add to deny list to permanently deny future requests from the IP address.

      • Block temporarily block requests from this IP address.

    8. Type the alert message text, in the Error message field, to be displayed when the policy is breached.

    9. Add IP addresses, in the Trusted IP Addresses field, that can be trusted and not blocked.

      • API Gateway supports IPv4 and IPv6 addresses in the trusted IP addresses lists.

      • You can specify a range of IP addresses using the classless inter-domain routing (CIDR) notation. To specify an IP address range, type the first IP address in the range followed by a forward slash (/) and a CIDR suffix.

        Example IPv4 address range:

        • 192.168.100.0/22 represents the IPv4 addresses from 192.168.100.0 to 192.168.103.255
        • 148.20.57.0/30 represents the IPv4 addresses from 148.20.57.0 to 148.20.57.3

        Example IPv6 address range:

        • f000::/1 represents the IPv6 addresses from f000:: to ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff.
        • 2001:db8::/48 represents the IPv6 addresses from 2001:db8:0:0:0:0:0:0 to 2001:db8:0:ffff:ffff:ffff:ffff:ffff.

      Click icon to add more than one IP address.

    10. Click Save.

    Managing Denied IP List

    The Denied IPs section has a list of client IPs that were denied access due to breach of denial of service by IP policy. You can delete the IP from the denial list and make it available on client’s request.

    To manage the denied IP list

    1. Click Policies in the title navigation bar.

    2. Select Threat protection > Denied IPs.
      This displays a list of IP address that are denied from access.

    3. Click icon in the Action column so that the specified IP can be made available.

    Configuring Rules

    You can configure rules to filter malicious requests based on message size, authentication requests, requests from specific mobile devices and applications that could be harmful, requests that could cause an SQL injection attack, requests on anti-virus scan, XML / JSON requests, or use custom filters to avoid malicious attacks.

    API Gateway applies rules in the order in which they are displayed on the Threat Protection > Rules screen. Because a violation of a denial rule stops API Gateway from processing a request, hence it is important to prioritize the rules based on the order in, which you want them to be executed. The API Gateway processes denial rules followed by the alert rules.

    To configure rules

    1. Click Policies in the title navigation bar.

    2. Select Threat protection > Rules.
      This displays a list of rules that are already configured.

    3. Click Add rule.

    4. In the Rule properties section provide the following information:

      a. Type a name for the rule in the Rule name field. Valid rule names:

      • Must be unique.

      • Must not be empty.

      • Must not contain spaces.

      • Must not contain the special characters - ? ~ ` ! @ # $ % ^ & * ( ) - + = { } | [ ] \\ : \” ; ‘ < > , /

      b. Type a description for the rule in the Description field.

      c. Select an action to be followed when the policy is violated:

      • Deny request and alert to deny the access and send an alert when the policy is violated.

      • Alert to allow the request and send an alert when the policy is violated.

      d. Type the alert message text, in the Error message field, to be displayed when the policy is violated.

      e. Select the required Request type to which you want to apply the rule and provide the additional information required.

      The available values are:

      • ALL: Applies the rule to all requests.

      • REST: Applies the rule to all REST requests.

      • SOAP: Applies the rule to all SOAP requests

      • INVOKE: Applies the rule to all INVOKE requests.

      • CUSTOM: Applies the rule to all requests specified by the custom directives. You can use this option if you want a single rule applied for multiple request types and custom directives.

      f. Provide the following information to filter the requests depending on the Request type selected:

      • Resource path: Provide the Resource path for the REST, SOAP, INVOKE, or CUSTOM Request type selected to filter the requests based on the resource being requested. The format for the REST, SOAP, and INVOKE request types is folder_name/service_name and the format for a CUSTOM request type is given_directive/service_name. You can add multiple resource paths using the Add button.

      • Custom directives: Provide the custom directives for the CUSTOM Request type to filter the incoming requests. For example, if you provide gateway as the directive, the rule applies to all these requests that are received in API Gateway with the directive gateway. You can add multiple directives using the Add button.

    5. Configure the required filters as follows:

      • Alert settings. Select one of the following options:

        • Default: Sets the default alert settings to be used.

        • Custom: You can specify this option to use the custom alert settings and provide the required information.

          • Alert destination: Specify the alert destination. Values are Email and Flow service. If you select Email, provide the email ids to which the alert notification has to be sent. If you select Flow service, a flow service is invoked. Specify the name of the flow service. You can create a flow service using the pub.security.enterpriseGateway:alertSpec as the signature of the service and or use the pre-defined flow service, pub.apigateway.threatProtection:violationListener. When you use the pre-defined service, the alerts are saved in API Gateway Data Store and displayed in API Gateway Dashboard. For more information on the pub.security.enterpriseGateway:alertSpec specification, refer to the Integration Server Build-In Services Reference Guide.

          • Provide the user, who has permissions to execute the service, as the user type. For example, Administrator

        Send alert: Select a condition depending on when you want the alert to be sent. Available values are On rule violation which sends an alert every time a request violates a rule or Every and specify the time interval (in minutes), which send alerts at specified intervals.

      • Message size filter

        • Set the Enable button to the On position to enable the filter.

        • Type the maximum size allowed for HTTP and HTTPS requests in the Maximum message size (MB) field.
          If the request is larger than the size specified in this limit, the request violates the rule and API Gateway performs the configured action.

      • OAuth filter

        • Set the Enable button to the On position to enable the filter.

        • Set the Require OAuth credentials toggle button to the On position. This implies the request should contain the OAuth credentials else the request would be denied.

      • Mobile application protection filter

        You can configure this filter to disable access for certain mobile application versions on a predefined set of mobile platforms. By disabling access to these versions, you are ensuring that all users are using the latest versions of the applications and taking advantage of the latest security and functional updates.

        • Set the Enable button to the On position to enable the filter.

        • Select the device type.

        • Select the mobile application.

        • Select the operator condition =, >, <, >=, <= or <>.

        • Type the mobile application version.

        You can add multiple entries by clicking icon.

      • SQL injection protection filter

        You can use the SQL injection protection filter to block requests that could possibly cause an SQL injection attack. When this filter is enabled, API Gateway checks each request message for specific patterns of characters or keywords that are associated with potential SQL injection attacks. If a match is found in the request parameters or payload, API Gateway blocks the request from further processing.

        • Set the Enable button to the On position to enable the selected filter.

        • Select the required filters as follows:

          • Select Database-specific SQL injection protection and select a database against which specific parameters needs to be checked.

            When enabled, API Gateway checks the incoming payload based on the specified database and GET or POST request parameters. If no parameter is specified, all input parameters are checked for possible SQL injection attack.

          • Select Standard SQL injection protection and specify one or more GET or POST request parameters that could be present in the incoming requests. Parameters can contain only alphanumeric characters, dollar sign ($), and underscore (_).

            You can add multiple entries by clicking icon.

      • Anti virus scan filter

      • You can use the antivirus scan filter to configure API Gateway to interact with an Internet Content Adaptation Protocol (ICAP)-compliant server. An ICAP server is capable of hosting multiple services that you can use to implement features such as virus scanning or content filtering. Using the antivirus scan filter, API Gateway can leverage the ICAP protocol to scan all incoming HTTP requests and payloads for viruses.

        • Set the Enable button to the On position to enable the filter.

        • Type the antivirus ICAP engine name in the ICAP name field.

        • Type the host name or IP address of the machine on which the ICAP server is running in the ICAP host name or IP address field.

        • Type the port number on which the ICAP server is listening in the ICAP port number field.

        • Type the name of the service exposed by the ICAP server that you can use to scan your payload for viruses in the ICAP service name field.

      • JSON threat protection filter

        You can use this filter to block attacks through JSON payload that have infinitely long strings or deeply nested payloads. Software AG recommends that this protection should be combined with message size filter to identify infinite payloads.

        Set the Enable button to the On position to enable the filter.

        You can specify any of these parameters as filter criteria. If you do not specify a value, the system applies a default value of -1, which means an unlimited value.

        Field Description
        Container depth Specifies the maximum allowed containment depth, where the containers are objects or arrays.
        For example, an array containing an object which contains an object would result in a containment depth of 3.
        Object entry count Specifies the maximum number of entries allowed in an object.
        Object entry name length field Specifies the maximum string length allowed for a property name within an object.
        Array element count Specifies the maximum number of elements allowed in an array.
        String value length Specifies the maximum length allowed for a string value.
        Applicable content type Specify any other content types to be included in the filter.
        You can add more entries by clicking icon.
      • XML threat protection filter

        You can use this filter to block attacks through XML payload that have infinitely long strings or deeply nested payloads. Software AG recommends that this protection should be combined with message size filter to identify infinite payloads.

        Set the Enable button to the On position to enable the filter.

        You can specify any of these parameters as filter criteria. If you do not specify a value, the system applies a default value of -1, which the system equates to no limit.

        Field Description
        Namespace prefix length Specifies a limit on the maximum number of characters permitted in the namespace prefix in the XML document.
        Namespace URI length Specifies a character limit for any namespace URIs present in the XML document.
        Namespace count per element Specifies the maximum number of namespace definition allowed for any element.
        Child count Specifies the maximum number of child elements allowed for any element.
        Attribute name length Specifies a limit on the maximum number of characters permitted in any attribute name in the XML document.
        Attribute value length Specifies a limit on the maximum number of characters permitted in any attribute value in the XML document.
        Attribute count per element Specifies the maximum number of attributes allowed for any element.
        Element name length Specifies a limit on the maximum number of characters permitted in any element name in the XML document.
        Text length Specifies a character limit for any text node present in the XML document.
        Comment length Specifies a character limit for any comments present in the XML document.
        Processing instruction target length Specifies a limit on the maximum number of characters permitted in the target of any processing instructions in the XML document.
        Processing instruction data length Specifies a limit on the maximum number of characters permitted in the data value of any processing instructions in the XML document.
        Node depth Specifies the maximum node depth allowed in the XML.
        Applicable content types Specify any other content types to be included in the filter.
        You can add multiple values by clicking icon.
      • Custom filter

        You can use the custom filter to invoke a service that is available on API Gateway to perform actions such as custom authentication of external clients in the DMZ, logging or auditing in the DMZ, or implementation of custom rules for processing various payloads.

        • Set the Enable button to the On position to enable the filter.

        • Click Browse and select a service to invoke it.

        • Select the user name of a user you want API Gateway to run the service. The default value is Administrator.

    6. Click Save.
      The new rule is created and appears in the list of rules in the Rules page.

    The rule is applied to requests only if the rule is enabled. You can enable the rule in the Rules page by selecting the enable icon for the required rule.

    Registering a Mobile Device or Application

    You can use API Gateway to disable access for certain mobile application versions on a predefined set of mobile platforms. By registering the required devices and applications and disabling access to these versions, you ensure that all users use the latest versions of the applications and take advantage of the latest security and functional updates.

    To register a mobile device or application

    1. Click Policies in the title navigation bar.

    2. Select Global Policies > Mobile devices and apps.

    3. Provide the mobile device type name and click icon.
      You can add more entries by clicking icon. You can delete the added ones by clicking icon.

    4. Provide the mobile application name and click icon.
      You can add more entries by clicking icon. You can delete the added ones by clicking icon.

    5. Click Save.

    Configuring Alert Settings

    You can configure the alert settings to control the following aspects of alerts that API Gateway sends when a request violates a rule:

    To configure alert settings

    1. Click Policies in the title navigation bar.

    2. Select Global Policies > Alert settings.

    3. Select one or both the alert destination types:

      • Email. This sends email alerts.

        • Type the email ids to which the email has to be sent.

      • Flow Service. This invokes a flow service to alert you of a rule violation. Specify the name of the flow service. You can create a flow service using the pub.security.enterpriseGateway:alertSpec specification as the signature of the service or use the pre-defined flow service, pub.apigateway.threatProtection:violationListener. When you use the predefined service, the alerts are saved in API Gateway Data Store and displayed API Gateway Dashboard. For more information on the pub.security.enterpriseGateway:alertSpec specification, refer to the Integration Server Build-In Services Reference Guide.

        • Provide the user, who has permissions to execute the service, as the user type. For example, Administrator.

    4. Select one of the following conditions depending on when you want the alert to be sent.

      • On rule violation to send an alert every time a request violates a rule.

      • Every and specify the time interval (in minutes) to send to send alerts at specified intervals.

    5. Click Save.