Skip to content

Instantly share code, notes, and snippets.

@ikromnurrohim

ikromnurrohim/Webmethods API Management Platform.md

Last active December 11, 2022 04:52
Show Gist options
  • Save ikromnurrohim/27ceeccb6a6634921dfb2669703b085f to your computer and use it in GitHub Desktop.
Save ikromnurrohim/27ceeccb6a6634921dfb2669703b085f to your computer and use it in GitHub Desktop.
Download ZIP
Webmethods API Management Essentials
Raw
Webmethods API Management Platform.md

Webmethods API Management Essentials

API Management

Applications Programming Interface

  • Allow connecting applications or computer systems in a standardized and flexible way
  • Enable exposing data functionality in web apps, mobile apps, and other connected devices
  • APIs provide new models for doing business
  • Transform the Internet into a platform for your business
  • API Economy - Value Creation API Provider -> App Developer -> App User | the user will be return the value off API Provider and we can monitize invocation of our APIs
  • API Portal
    • API & APP Gallery
    • Collaborate & Communication
    • Reporting & Analytic
    • API Packages & Subcription
    • Multiple API Type (Rest, SOAP and other)
    • Instant API Try-Out
  • API Economy - API Provisioning and Management
    • API Provider
      • Create APIs
    • API Provider & Manager
      • Prepares APIs for consumtion
      • Manages APIs roadmaps
      • Manages relationship between consumers and producers
      • Understand API Usage
    • API Consumer
      • Build solution using APIs Tools to support API Provisioning and API Management
    • webMethods API Gateway
      • API Management
      • Analytic
      • Multiple API Style (Mashup)
      • Policies
      • SLA
      • Publish to webMethods API Portal


API Creation Supported Types and Specifications

  • Supported API Types:
    • SOAP
    • REST
    • OData
    • WebSockets
  • API Specification Format
    • SOAP WSDL
    • REST Swagger (version 2.0) OpenAPI (version 3.0) RAML (RESTful API Modeling Language)
    • OData (Open Data Protocol) OData metadata document
      API Creation Supported API Creation:
  • Import File (single file or zip file)
    • REST need (Swagger or OpenAPI or RAML) definition
    • SOAP need (WSDL) definition
  • Import From Url
    • REST
    • SOAP
    • OData
  • Create From Scratch
    • REST
    • WebSockets
  • Publish from Integration Server or Centrasite
    • REST
    • SOAP


API Creation

  • You can add wich Team can consume that APIs by select on menu before you saving on creating new API, but this button by default is None, you can add this button by Administrator and go to Extended settings > enableTeamWrok = true
  • You can also add multiple Maturity State by go to Extended settings > apiMaturityStatePossibleValues
  • You can also add multiple API Group by go to Extended settings > apiGroupingPossibleValues
  • You can add multiple native endpoints, and you can use content base routing protocol to route specific message to specific enpoint. you can enforce specific route messages to different enpoint base on specific value from the consumer provide the request message


Packages & Plans

  • Monitization in API Gateway:
    • Monitization of APIs is based on Pakcages and associated Plans
      • Plan defines offerings with availability guarantess, SLAs and cost structures
      • Package is a group of APIs associated with multiple plans
    • Pakages and Plans can be published to API Portal for Consumer
    • Consumers subscribe to a Pakage-Plan combination as the contract between consumer and provid


API Mocking

  • simulation non existing backend service
    • you can test case using api mocking where the api was be develop and not ready yet. so you can design first and test on consumer can now work on paralel this also reduce time design to production
    • you can provide intentions of perfomance api which can simulate the new result
    • in all cases backend resource is not invoke when api mocking enable
  • API Mocking it's only available on REST and SOAP API
  • to enable mocking you first have to deactivate API, you cannot enable or disable mocking on API which is already activated
  • Mock payload base on the request, moack payload allows for variable request information
  • Mock payload also base on condition parameters
    • Header (SOAP, REST)
    • Query (REST)
    • Request Body (SOAP)
  • Mock payload based on costum logic in Integration Server(is) service to return mocked response
  • Priority of a Mock Response
    • Proirity of generating the default mock response at design-time
      • -> Sample
        • -> Schema
    • Priority of sending a mock response at run time
      • -> Condition-based
        • -> ESB service
          • -> Default mock response


SOAP (Simple Object Access Protocol)

  • message format based on xml, soap header and body. soap messages can be exchange using different protocol like http https jms smtp
  • structure inbound and outbound is define by wsdl (web service definition leanguage) is document with defin type messages operation, port binding and port of webservice it self
  • WS-Security using security token


Publishing from Integration Server

  • before publishing you must be configure connection on your designer to connecting api gateway

  • type REST and SOAP

  • make rad (rest api description) to utiles rest service or web service descriptor lenguage

  • right clik on rad and publish

  • if the api is exist. re publish will overide api on api gateway

  • one thing that important is you cannot unpublish or retract rest api or soap api. so you must delete the api in api gateway

    Publish from Centrasite: Publish virtual service from Centrasite on video https://learn.softwareag.com/ mod/book/view.php?id=12146&chapterid=4527

    Edit API (2 Operations) :
    Deactivte first and then edit
    Switch directly to Edit Mode while API is still active. Edit whitout deactivate (Hot Deploy)

    Update API : Overwrites an existing API definition Retains the exposure to consumer settings

    Create New Version : Available in active and non-active state of the the API the new version has the new version number Activating the new version will result in a new proxy API

    API Gateway Endpoint Services :

    • Gateway endpoint services in PI Gateway act as proxies for native services
      • Adding Policies to Switch protocols (HTTP/S,SOAP 1.1/1.2)
      • Support different routing methods
      • Secure access,monitor,log, validate,...
      • Transform request/response to ensure compatibility


Policies

is kind of rules, where every api on api gateway mandatory have policies.
Policies can be add on:

  • policies Globaly (Globaly will effect to all API if the policies is possible to be apply to API)
  • policies on API level
  • policies on scope level for Resource and Mehtod (Rest API) and for operation (SOAP API)

Request Handling

Transform request to ensure compatibility

  • Switch Protocols
    • HTTP(s)<->HTTP(s)
  • Set Media Type
    • Content-type for request if not specified in the request header
  • Request Processing
    • Invoke webMethods Integration Server
    • Request Transformation
    • Data Masking
    • Validate API Specification

Identification Management:

  • Client Identification & Authorization
  • Ensure Confidentiality & Integrity API Security Policies
    • Client Identification
      • Authentication Confirm identity via digital certificate, password or token
    • Authorization
      • Limit access to data & services based on identity
    • Confidentiality
      • Encrypt data to prevent interception
    • Integrity
      • Ensure data has not been tampered on the way
    • Consumer <-> Application mapping
      • How to identify and validate clients who are trying to access the API as consumers in API Gateway


Traffic Management

Logging & Monitoring

  • Monitor and collect information about the number of messages processed
    • Log Invocation
    • Monitor Service Level Agreement
    • Monitor Service Performance

Traffic Throttling

  • Avoid overloading the back-end service
    • Throttling Traffic Optimization (limit the number of calls)
    • Service Result Cache

Routing Management

  • Route incoming message
    • Content Based Routing
    • Context Based Routing
    • Custom HTTP Header
    • Load Balancer Routing
    • Dynamic Routing
    • JMS Routing/JMS Properties
    • Custom Outbound Authentication (Transport/Message layer)
    • Verify that the client has the proper credentials to access the native API


Response Processing and Error Handling

Transform response to ensure compatibility

  • Response Processing
    • Invoke webMethods Integration Server
    • Response Transformation
    • Data Masking
  • Error Handling
    • Error Conditions
    • Failure Messages
    • Custom Error Variables
    • Pre- and Post-Processing


Expose to Consumers-REST API

  • if you have one API with 2 operation, and you just want to expose 1 of them to consumer, you can disable "expose to consumer" on tab Resource and Method in API Details


Indentification Management

  • Concepts to identify consumers and to authorize API invocations
  • Policies defining different security mechanisms to protect an API
  • Identication and Access Management:
    • 4 Pillars of Security:
      • Identification/Authentication is the act of proving an assertion, such as the identity of a computer system user
      • Authorization to control access privilages grant to user or program, or browser
      • Confidentiality to ensure that information enclosed, is not disclosed to user, user device or browser under they are authorize. printed the data by encrypting to prevent interception
      • Data Integrity entity is not being modify


Runtime Security

  • Transport-layer Authentication and Consumer Identification (SOAP and REST)

    • API Key
    • HTTP Bacis Authentication
    • Bearer Token: Kuberos/Oauth2/JWT/OpenID Connect
    • Hostname Address / IP Address Range
    • SSL Certificate
    • Payload element (XPath, JSONPath, Text)

  • Message-layer Authentication and Consumer Identification, Encryption and Signing (SOAP)

    • Token Assertions
    • Require WSS X.509 Certificate
    • Requeire WSS Username Token
    • Kuberos Token Authentication
    • Require SAML Token
    • Custom Token Assertion
    • Require Encryption
    • Require Signature

  • Identify and Access Policies in API Gateway

    • Inbound Authentication - Message
    • Identify & Authorization Application

  • Authorization Policies in API Gateway Authorization is process to check consumer is allowed to invoke the API. different policies authorize the consumers accesing the APi

    • Authorize User this policies allow to authorize user base on the list of user, team or group that configure on this policies
    • Identify & Authorization Application


Security at Transport Layer

  • User credentials and claims are passed by using the transport layer
  • User SSL for encrypting and signing the contents of the packets sent over HTTPS
  • Advantage
    • Provides interoperability
  • Disadvantage
    • Point-to-point security with no provision for multiple hops

Enforcing Inbound Authentication (Transport Layer)

Policy Identify & Authorize Application

  • Protect Gateway service based on enforced user identification/authentication
  • Availaible for REST and SOAP APIs

Message Layer

means all information that require to perform and check encapsulated in every message

  • User credentials and claims are encapsulated in every message using WS-Security
  • Advantages
    • Transport independent
    • Any type of security credentials can be used
    • Multiple hops don't break security
  • Disadvantages
    • May reduce performance

Enforcing Inbound Authentication (Message Layer)

Policy Inbound Authentication - Message

  • To configure WS-Security actions evaluated by API Gateway
  • SOAP APIs only

Configuring of WS Security Settings in API Gateway

  • defining keystore and trustore as well as client cerificate wcich can be configured on api gateway administration

Inbound Authorization

  • Inbound identify & autorhize applications policy

Enforcing User Authorization

  • Policy User Authorization by
    • list of defined Users
    • list of defined Groups
    • list of defined Teams
      Policy User requires for a dependent authentication policy -> Identify & Authorize Application (default) or Inbound Authentication
  • Inbound Authenctication - Message (SOAP APIs)


Application Management

What is Application in API Gateway ? Application is an object, start and created in api gateway. task for Application is Identify first incoming request. if you enforce identification of consumer by using identify authorize application policy, api gateway will try to find a matching application. matching application means the user id, password or token is provide matches to an application exist on api gateway. if the consumer identify match, request can be next step (invoke backend service)

Some Terminology

  • Application is an object on api gateway, you create them and you provide
    • "basic information" (name or description)
    • "identifier" can quite simple user id and password or you enforce http authentication
      • "key" like api key or oauth2 something to identify incoming request

Application -Design Time and Runtime

  • Design Time action by API Provider :

    • create Application and define identification criteria

    Optional : mapping between application and APIs (registered application)

  • Runtime Consumer invoke an API, thi API secure by identify authorize application policy. API Gateway try to find an application which matching identifier, if this can be found. the consumer is identify and authorize to invoke the API

    At Runtime "when API Gateway finds one identifier matching one value in the application, the access will be granted"

  • Runtime action by API Gateway

    • identify consumer via precise identifiers defined in a matching application
    • control api access to dentified consumers (authorization)
    • monitor (in kibana dashboard) an API for violation of SLA for a specified application

Defining Identifiers at an Application

  • Definition of multiple values of the same Identifiers Type is valid
  • Multiple Identifiers Types can be defined
  • API Key will always be generated when creating the Application

RUNTIME
When API GATEWAY finds ONE identifier matching ONE value in the > Appplication, the access will be granted

Identifier Types at an Application

  • IP Address Range
    Define a range of IP addresses
  • Partener Identifier B2B (bussines to bussines)
    Provide 3rd partner's identity
  • Client Certificate
    Upload Client certificate(s)
  • Claims
    • Set of claims for JWT and OpenID Connect clients
    • Name-value pair defines unique identifying information
  • Other Identifiers
    • Hostname, Token, Username, WS-Security username, Payload identifier, Team


Policy Identify & Authorize Application

  • Identify & Authorize Consumer
    based on Identification Type
  • Authorize Consumer
    based on Application Lookup Condition consumer

Configure Identification Criteria

Identification Types

  • Allow Anonymous Access
  • Hostname Address
  • IP Address Range
  • Payload element (custom token)
    • XPath expression
    • JSONPath expression
    • Regular expression
  • Access Tokens (API Key, OAuth2, JWT)
  • Transport Layer (HTTP Basic Authentication, SSL Certificate, Kuberos Token, OpenID Connect)
  • Message Layer (only for SOAP) - (WS Security Username token, WS Security X.509 Certificate) \

Criteria can be combined (And / Or)

Configure Application Lookup Condition

Define the list of Applications against which the consumer identifier should be validated

  • Applications Lookup Condition
    • Registered applications
      Example we have policy with basic authentication with application lookup condition Registered Applications
      At runtime Consumer passing username and password on request header, in api gateway first check it is user define on api gateway, if yes the policy get enforce, policy Identify & authorize application executed and now try to find on application which was linked with that api (called registered applications) with identifier type username with the matching value with username password. if it is one registered application can be found at runtime then matches condition Identification type and application lookup condition, the consumer is identified and also authorize to call the api. because we have specify application lookup condition Registered Applications this need that the application linked to api
    • Global Apllications
      Example we have policy with basic authentication with application lookup condition Global Applications
      At runtime Consumer passing username and password on request header, in api gateway first check it is user define on api gateway, if yes the policy get enforce, policy Identify & authorize application executed and now try to find any application with identifier type username with the matching value with username password. if it is one application can be found at runtime, then matches condition Identification type and application lookup condition the consumer is identified and also authorize to call the api. because we have specify application lookup condition Global Applications this no need that the application linked to api
    • Global Apllications and default Application \

API Key / OAuth2 Token Identification

Example we chosen Identify & Authorize Application API Key or OAuth2 Token with application lookup condition Registered Application
at runtime when we have configured policy with API Key or OAuth2 Token consumer must be passing API Key or OAuth2 Token at the request, API Gateway will be extract the API Key introspect the OAuth2 Token from the consumer request and again try to find matching application which provided same API Key or OAuth2 Token if one application exists and application has linked to the api, the consumer right to invoked, the consumer is identify and authorize to invoke the api. which mean found matching application must have same identifier, API Key or OAuth2 Token being configure

Default, Global and Registered Application

  • Registered Application

    • Matching Application must exist on API Gateway
      Matching mean the Registered Application must have same identifier type and the value of identifier type matching with the incoming request then the application match
    • API Must be asigned to Application that why called Registered Application

    API Gateway determines at runtime wheter the consumer can be mapped with an existing Application to which the API is assigned

  • Global Application

    • Matching Application must exist on API Gateway
      Matching mean the Global Application must have same identifier type and the value of identifier type matching with the incoming request then the application match
    • In the Global Applicatiom not required the API linked to some assosiated application

    API Gateway determines at runtime whether the consumer can be mapped with any existing Application

  • Global Application and defaultApplication
    this bit like open door

    • Matching application can exist on API Gateway
    • If no matching application can be identified, consumer mapped to (non-existing) "defaultApplication"

    Whatever know application can be found, in this case consumer is identified and authorized to invoke the API

    but if you want to use application lookup condition Global Application and defaultApplication you may add additional policy Authorize User, to authorize user incoming request. at runtime if user not availabel on configured policy Authorize User then the user cannot invoke the API

Application - API Assignment

  • We can assign API to the Applcation level when we create or edit Application
  • We can assign Application on API level when we create or edit API

API Key as Identifier Application

  • Challenge
    Secure APIs where external consumers are still unknown
  • Solution
    • Consumer passes API Key in when calling an API
      • to identify & authorize (unknown external) consumer
      • to track and control how the API is being used
      • prevent malicious use or abuse
  • API Key can be create when you created application
  • you can also Regenerated the API Key
  • API Key passes on header with
    Key Value
    X-Gateway-APIKey API Key
  • API Key Expiration Period
    If you want to set how long API Key can be valid to access the API, you can setting the apiKeyExpirationPeriod on Extended Settings if you want to setting to 10 month, the value is 10m, 15 minutes is 15m. and If you do not specify a value, the API Key never expires

Application Approval Workflows

  • Configure under Administration -> General -> Approval configuration
  • Administration privilage is required
  • 3 Application workflow to be configured
    • Create Application
    • Register Application
    • Update Application
  • Configure setting
    • Enable or disable workflow
    • Approvers Team
    • Apporval mode
    • E-mail templates
      • "Approval initiate request", sent to approver(s)
      • "Request approved" sent to requester
      • "Rejection" sent to requester
  • Functional Privilages for Approving an Application Manage Applications
    • Approvers of an Approval Workflow must be a
      • User associated with the selected Team which includes funtional privilages*Manage Applications**
      • User associated with the Administrator Team
  • Approval can be see on menu Pending Requests

Managing Applications - Summary

  • API Gateway Provider creates API in the API Gateway
  • API Gateway Provider adds an Identify and Authorize Policy
  • API Gateway Provider creates an Application to control access to the API
  • API Gateway at runtime tries to find a match on identifiers passed by the consumer
  • API Gateway Provider and API Gateway Administrator can manage Applications and Approval workflows


Global Policy Management

Threat Protection in API Gateway

Exposing APIs to External Consumers

Use Case

  • APIs residing in internal applications are behind a firewall
  • External consumers - mobile apps - are not allowed to communicate with API Requirements
  • Secure the APIs with DMZ-level protection
  • Manage and govern the use of the APIs Solution
  • API Gateway
    • Located in the DMZ
    • Impose Threat protection and security rules on the request

Threat Protection

Threat Protection Rules (Policies)

  • Control which requests are forwarded to internal IS or API Gateway
  • Protect against various kinds of threats and attacks
    • Denial of Service (DoS global or based on IP addresses)
    • Trusted IPs (white-list of IP addresses)
    • Filtering
      • Message Size, Mobile Application & Devices, SQL Injection
      • Antivirus Scan
      • Custom

Reverse Invoke

means API Gateway on DMZ have External Port (to comunication consumer) and Registration Port (to communication between internal service like API Gateway on LAN, Integration Server on LAN).

SCENARIO
A. API Gateway on DMZ as threat protection and API Gateway on LAN
B. API Gateway on DMZ as threat protection and Integration Server on LAN

  • Screnario A

    • Port Configuration at Threat Protection API Gateway (Running on DMZ)
      go to Administration > Security > Ports then select Type API Gateway External
      API Gateway external listener configuration Specify External port and Alias
      API Gateway registration listerner configuration sepcify Registration port and Alias

      External Port to comunication between consumer API
      Internal Port to reverse comunication to the inner API Gateway

      After configuration, Enable both Ports

    • Port Configuration at the Internal API Gateway (Running on the LAN)

      wee need to configure this if we have scenario one API Gateway on DMZ as threat protection and one API Gateway on LAN

      wee need to configure and enable Internal Port which is use to send reverse request to the Registration Port of API Gateway in the DMZ

      go to Administration > Security > Ports then select Type API Gateway Internal
      API Gateway internal listener configuration Specify the Alias
      API Gateway external server sepcify Host and Port
      Registration credential (optional) (Registration credential for API Gateway on DMZ) Provide credential to allowing this connection to the Registration Port at the API Gateway on DMZ

      This Port will use to send reverse request to the registration port of API Gateway on DMZ

      Reverse Invoke - Adjust API Gateway Endpoints

      • API Gateway for Threat Protection in DMZ as Reverse Proxy Server
      • API Gateway in internal network with configured APIs
      • Adjust Gateway endpoints (on internal network) of defined APIs to go through API Gateway in DMZ
        • Insert Load Balancer definition at the Internal API Gateway

        Administration > General > Load Balancer and provide url of external port Threat Protection API Gateweay (in DMZ)

    • Screnario B

      • Port Configuration at Threat Protection API Gateway (Running on DMZ)
        go to Administration > Security > Ports then select Type API Gateway External
        API Gateway external listener configuration Specify External port and Alias
        API Gateway registration listerner configuration sepcify Registration port and Alias

        External Port to comunication between consumer API
        Internal Port to reverse comunication to the inner API Gateway

        After configuration, Enable both Ports

      • Port Configuration at the Internal Integration Server (Running on LAN) go to Administration > Server > Ports > Add Port > select Port Type Internal Server

        Table Inetnal Server
        Enable Yes
        Protocol HTTP/HTTPS
        Package Name WmRoot
        Alias InternalPortAlias
        Description (optional)
        Max Connections 5
        Threadpool Enable
        Table Enterprise Gateway Server
        Host (Host API Gateway on DMZ)
        Port (Port Internal on API Gateway on DMZ)
        Table Registration Credential (Optional)
        Username (Username API Gateway on DMZ)
        Password (Pasword on API Gateway on DMZ)
        Table External Client Security
        Client Authentication Username/Password

        This Port will use to send reverse request to the registration port of API Gateway on DMZ

        Reverse Invoke - Adjust API Routing Endpoints

        • Routing endpoint of an API already created on API Gateway in DMZ has to use the Registration Port Alias name as defined in the external port configuration
        • Adjust Endpoints URI in APIs Straight Through Routing policy
          Example http://apigwateway:**RegistrationPortAlias**/rest/api/ resource

          Click on API > Edit API > Policies > Routing > Straight Through Routing on Endpoint URI provide http:// apigwateway:RegistrationPortAlias/rest/api/resource

    Threat Protection - Overview

    Global Denial of Service

    • Global Denial of Service protection is a global entity, and it is applied to all API requests irrespective of IP, region or request type
      Global Denial of Service by IP
    • Denial of service by IP protection is an IP specific protection, and it is applied to all the requests
    • Support for a White-List of trusted IP addresses
      Rules
    • Filter malicious requests based on predefined criteria or custom filters
      Mobile Devices and Apps
    • Disable access for certain mobile application versions on a predefined set of mobile platforms

    Threat Protection Alert Settings

    Can be configure on

    • Global level
      on tab Policies > Threat Protection > Alert Settings

    • Rule level
      on tab Policies > Threat Protection > Rule > Alert Settings

      Alert Setting on Rule level can overwrite Global Alert Settings

    • Configure Alert Settings
      Configuration is the same on Global and Rule level

      • Possible Allert Destinations
        • None
        • Email to e-mail account
        • Flow service sending Flow Events visible in global Threat protection dasboard (Analytics)
      • Email Ids
        • List of e-mail recipients being alerted
      • Service definition
        • Namespace of the invoked IS Flow service
      • Run as user
        • User in order to run the IS server
      • Send Alert
        • On rule violation
        • Every (time interval in minutes)

    Denial of Service (DoS) Attacks

    • Ping of Death
    • Teardrop attacks
    • Exploit limitations in the TCP/IP protocols

    Configuring Global DoS Policy

    • Global entity
      • Applied to all requests
      • Irrespective of IP, region, request type

    Example Global Denial of Service

    Table DoS
    Enable True
    Maximum request 1000
    In (seconds) 100
    Maximum requests inprogresses 250
    Block intervals (minutes) 2
    Error Message Recieving too many requests. Rejecting all requests and entering passive mode !!!
    Trusted IP addresses 127.0.0.1
    • The consumer send 1001 request within 100 seconds
      Consumer will get an error message as configured and response code 403
    • Different consumer sends additional request within the same time interval
      2nd consumer will get the same error

    Configuring DoS by IP Policy

    • IP specification protection, applied to all requests
    Table DoS by IP Description
    Maximum request 300
    In (seconds) 20
    Action when limit exceds Add to Deny List or Block Choise Add to Deny List or Block
    Block intervals (minutes) 10 Blocking the IP for further 10 minutes
    Error Message Recieving too many requests from this IP. Blocking the IP for 10 minutes
    Trusted IP addresses 127.0.0.1 Configure a white-list of IP addresses so that requests from these IP addresses are always allowed
    • Consumer sends 300 request withing 20 seconds
      Consumer will get an error message as configured and the response code 403
      Consumer added to Deny List or gets Blocked n minutes
    • Different consumers invoking the same API from the other IP or Trusted IP
      Consumer will get a successful response

    Managing Denial IP List

    List of IP addresses that have violated the DoS by IP Policy.
    tab Policies > Threat protection > Denial IPs

    • Administrator checks this list and determines further activites
      • Reliable IP -> Remove from the list

    Configuring Rules

    Configure to filter malicious request based on different criteria
    Rule is Action when a Filter configuration is violated.

    • Filter Configuration
      • Predefined and custom filter
      • Alert settings
    • Action
      • Deny request and alert
      • Alert only
      • Always returning defined Error message
    • Request type - apply rule to
      • All
      • REST
      • SOAP
      • Invoke
      • Custom

    Alert Settings and Filters

    Alert Settings

    • Default
      Global Alert settings
    • Custom
      Rule-specific configuration

      Various Filter Type
    • Alert settings
    • Message size filter
    • OAuth filter
    • Mobile application protection filter
    • SQL injection protection filter
    • Anti virus scan filter
    • JSON threat protection filter
    • XML threat protection filter
    • Custom filter

    Filter can be combined to create rules that are applicable globally as Threat Protection Policies

    Message Size Filter

    In cases the native server cannot process very large incoming requests

    Table Message size filter
    Enable True
    Maximum message size(MB) 1

    OAuth Filter

    In order to require OAuth credentials provided by the consumer

    Table OAuth filter
    Enable True
    Require OAuth credentials True

    Mobile Application Protection Filter

    Disable acess from certain mobile application versions on a set of mobile devices

    • Ensure that all users use the current versions of applications
    • Usage of latest security and functional updates
    • Filter options :
      • Device Type-specific Filter
      • Mobile Application-specific Filter
    • Device types and Mobile applications must be defined under Mobile devices and apps first
    • Use defined mobile device types and apps in Rule with Mobile Application Protection Filter

    Database-Specific SQLI Protection Filter

    Prevent from sending malicious SQL code for backend database manipulation

    • Select Database-specific SQL injection protection
    • Select database type
    • Provide Parameter Definitions
    • Enable Rule
    • API Gateway will block the request when the selected parameter contains an invalid special character
      Example

    http://localhost:7777/gateway/PetStoreAPI/pet?userID=,jd&password=test

    Standard SQLI Protection Filter

    • Select Standard SQL injection protection and do not select Database
    • Optional: Provide HTTP Request Parameters
    • Enable Rule

    API Gayeway will check the parameters to contain only alphanumeric characters, dollar sign($), and underscore(_)
    If no parameter is defined, all parameters are checked

    Sample: API Gateway will block XML/SOAP Payload messages containing

    • Quotation mark (')
    • Number sign (#)
    • Double hyphen (--)
    <Employe> 
<ID>13</ID>
<NAME>Albu'n name</NAME>
<DESTINATION>SS#E</DESTINATION>
<COUNTRY>USA--</COUNTRY>
<DOJ>2014</DOJ>
</Employe>

    Antivirus Scan Filter

    Scan HTTP request & payload for viruses Enable API Gateway to interact with an Internet Content Adaption Protocol (ICAP) Server for

    • Virus Scanning
    • Content filtering
      Pre requisites
    • ICAP-compliant server installed and configured in DMZ
    • API Gateway must be able to access this server
    • ICAP-compliant server must have an ICAP service registered
    • API Gateway must be able to send emails to that server

    JSON/ XML Protection Filter

    Block attacks through JSON/XML payload having

    • Infinitely long strings
    • Deeply nested payloads

    Recomendation
    JSON/XML Threat protection filter should be combined with Message size filter to identify infinit payload

    Custom Filter

    Invoke service available on API Gateway / Integration Server

    Table Custom Filter
    Enable True
    Invoke Service custompack.rules:myCustomRule
    Run as user Administrator
    Usage
    • Custom authentication of external clients in DMZ
    • Logging and auditing in DMZ
    • Custom rules for processing various payloads
      • Extract HTTP headers and payload
      • Add custom headers and custome response codes

    Threat Protection Dashboard

    • Analytics > Threat Protection Rules widget
    • Analytics > Threat Protection Filter widget
    • Analytics > Threat Protection Event widget

Global Policies

Only enabled for users with sufficient permissions, e.g. API-Gateway-Administrators

Ineffecient One-to-One Policy Definition

Oftentimes, the same Policies must be applied for multiple APIs. then why not share Policies to reuse them. this is the concept of global policy in API Gateway

A Smarter Way : Global Policies

APi Management with efective Global Policies.

What is Global Policies ? Global Policies is consist of Set of Policies and this set of Policies can be attach and define at the Global Policy

  • Associate a group of Policies to set of APIs filtered by conditions
  • Global Policy takes precedence over all other (API and scope-level Policies)
  • Modifying a Global Policy will effect all the associated APIs
  • Policy modifications can be propagated without downtime

Benefit : Dynamic scope, applicable to multiple APIs

Only active Global Policies will be added to affected APIs

Global Policy in API Policy Definition

Activated Global Policy applied to the API
Policy with a Globe icon is a Global Policy applicable to an API

Activating and Deactivating a Global Policy

  • Global Policy overview page
  • Global Policy detail page

Changing a Global Policy

Global Policies can be modified in any state (active/inactive)

Using Global Policies

Sample A

  • Provide Basic Authentication for all APIs HR
  • Monitor service performance of all APIs HR
    Sample B
  • Provide authentication based on API Key for all APIs HR
  • Enforce Throttling for all APIs HR

Scope Level Policies

API Scopes

Use Case
Shoping API have Resources

/orders /orders/{orderID}
GET GET
POST DELETE


Requirements

  • Enforce logging for a specific resource or method
  • Enforce a higher security for POST/DELETE Operation
    • Consumer should match with a registered Application Solution API Scope - Fine granular Policy definition for a subset of the API

API Scope REST is logical grouping of resources and method of REST API

API Scope SOAP is logical grouping of operation of SOAP API

API Scope have some restriction there are restricted to one API these mean each API have set of own set of Scope, Scope cannot be share accros multiple API. and name of one Scope in one API must be Unique

Policy Definition for API Scopes

API Details tab Policies on Select scope select the API Scope to define a set of Policies just for members of this Scope. if you have been create API Scope (on API Detail), in tab Policies the dropdown can showing that Scope and if you select that scope you can define Policies at your API which are restricted to their fine Scope only

Policy Types for API Scopes

Scope-level Policies only of type

  • Identify & Access
  • Traffic Monitoring

Two above is from the Videos on learning software ag but when I check that Types allow is

  • Identify & Access
  • Traffic Monitoring
  • Request Processing
  • Reponse Processing
  • Error Handling

Policy Precedence

  1. Global Policies is always the one which take precedence our ares
  2. API Scope-level Policies for a method/operation of REST or SOAP API
  3. API Scope-level Policies for a resource (REST only)
  4. API Level Policies

At runtime API Gateway will execute Policy by Precedence 1 then 2 then 3 then 4.

Policy Templates

Object in API Gateway can be define and consist of the set of Already define and tested Policies. Acting shomehow as a Blueprint and is a template we can take this template and apply to one or multiple API

Create Policy Template

  • create from scratch on Tab Policies (on top menu) -> Policy Templates
  • create from existing on Tab Policies (on api detail) on bottom right click on Save as template

If you applied Policies from Policy Template you can select what you want to applied. example the Policy Template have Traffic Monitong and Response Processing, after you applied Policy Template you can remove Response Processing if you just want to applied Traffic Monitoring.

When applying Policy Template then have Confilcts, you can delete the other you don't want to applied

Create and Maintain a Policy Template

User must have the API Gateway's Manage Policy Template functional privilage assigned

Traffic Management

To enforce Policy to logging monitoring information about number messages proccess, how many successful, how many failure, number of calls or avarage, min and max response time. for that purpose there are three policies Log Invocation, Monitor Performance and Monitor SLAs.

To enforce Policy to avoid overloading backend service :
Traffic Optimization which limit the number of calls
Caching Service Results to improve performance

API Traffic Monitoring Policies

  • Log Invocation
    Logging of external access
  • Monitor Performance
    Monitoring of a service by configuring rules that are based on service performance parameters
  • Monitoring SLA
    Monitoring of a service based on consumer SLAs
  • Traffic Optimzation
    Regulate the asset usage
  • Servicr Result Caching
    Reduce latency of invoke services

Traffic Monitoring and Events

Traffic Monitoring requires for configuring of Events.

  • Possible Destinations for publised Events :
    • API Portal
    • Transaction logger
    • Centrasite
    • Database
    • Digital Events
    • Elasticsearch
    • Email
    • SNMP \
  • Event types turned on by destionation :
    • Error
    • Lifecycle
    • Policy violation \
  • Events Types which are always turned ON/always sent :
    • Transaction Events
    • Monitoring Events

By Default Events published to Destination API Gateway

Event Types in API Gateway

Event Type Description
Lifecycle Occurs each time API Gateway is started or shutdown
Error Occurs each time an invocation of a virtual service results in an error
Policy Violation Occurs each time an invocation of a service violates a run-time policy
Transactional API Gateway publishes transactional events in case a log invovation run-time policy is configured (Logging)
Performance Data Occurs based on the performance reporting interval
Monitoring Occurs when monitoring service performance or SLA policies are violated

Analityc Dashboard - Visualize Runtime Events

API-related and globally

Log Invocation Policy

  • Used to record the invocation of an API
  • Generates a Transactional Event for every API request

Configure API Details -> Policies on Log Invocation

  • Payload storeage and its format
  • Log generation frequency
    • Always
    • On Failure
    • On Success
  • Destionations by default is on API Gateway

Destination Audit Log is the analyze on Integration Server not the Audit Log of API Gateway

Monitor Performance Policy

Got To Documentation SAG
Allow to monitor an API by configuring rules that are based on performance parameters
Configure :

  • Action condition
    Name Operator Value
    Availability Equals To, Less Than, Greater Than
    Average Response Time Equals To, Less Than, Greater Than
    Fault Count Equals To, Less Than, Greater Than
    Maximum Response Time Equals To, Less Than, Greater Than
    Minimum Response Time Equals To, Less Than, Greater Than
    Success Count Equals To, Less Than, Greater Than
    Total Request Count Equals To, Less Than, Greater Than
  • Destination(s) for the emmited Events
  • Alert interval and time unit
  • Alert Frequency
    • Only Once
    • Every Time
  • Alert Message

User can add multiple monitoring Policies for a particular API
If one of the rules is violated, monitoring alert events are generatd

Monitor Service Level Agreement (SLA) Policy

Got To Documentation SAG
Monitoring SLAs for a particular Application
This policy monitors a set of run-time performance conditions for an API, and sends alerts to a specified destination when the performance conditions are violated. This policy enables you to monitor run-time performance for one or more specified applications. You can configure this policy to define a Service Level Agreement (SLA), which is a set of conditions that defines the level of performance that an application should expect from an API. You can use this policy to identify whether the API threshold rules are met or exceeded. For example, you might define an agreement with a particular application that sends an alert to the application if responses are not sent within a certain maximum response time. You can configure SLAs for each API or application combination.

Parameters like success count, fault count and total request count are immediate monitoring parameters and the evaluation happens immediately after the limit is breached. The rest of the parameters are Aggregated monitoring parameters whose evaluation happens once the configured interval is over. If there is a breach in any of the parameters, an event notification ( Monitor event) is sent to the configured destination. In a single policy, multiple action configurations behave as AND condition. The OR condition can be achieved by configuring multiple policies. \

Requires for a depent additional Identify & Authorize Policy
Determines the matching Application

Traffic Optimazation Policy

Got To Documentation SAG
Limit the number of API invocations during a specified time interval for predicable operations
so you control the amount of traffic reach in the backend using this policy and you can avoid overloading of backend
Configure

  • Total request limit
  • Destionations(s) for the emitted Events
  • Alert interval and time unit
  • Alert Frequency
  • Custom alert message
  • Consumer Application

Requires for a depent additional Identify & Authorize Policy
Determines the matching Application

Service Result Cache Policy

Go To Documentation SAG
Improve throughput and latency by caching service responses of backend services
Instead of invoking the backend service for every consumer request, cached result is used.

Benefit

  • Faster responses
  • Reduce number of network calls
  • Helps when server is temporarily down

Configure

  • Cache criteria
  • Time-To-Live for Cache Data
  • Maximum Response Payload Size

Considerations
Configure cache criteria properly that define the payload

  • What is the KEY for the lookup in the cache => unique identifier
  • Make sure to identify the correct data -- you need to know the data context/content
    Only one set of criteria is supported
    Caching results will very depending on your backend service responsiveness

Backend with low latency/response time will not greatly benefit

Caching is recomend if data does not change frequently, request to database has high response time and consumer can use likely authenticated cache data.

No caching recomend if the reponse from database already very fast

Behind the scenes API Gateway usage Ehchace capability provided by Integration Server and Terracota to cache the result of API calls.
you can configure Service Result Caching for single API Gateway node or for Cluster.



Routing, Transformation and Mediation

Request Routing and Outbound Authentication

Routing Use-Cases

  • Route the order request to the nearest fulfillment provider based on location passed in the Protocol header
  • Route request to backend services located in another domain
  • Comply with backend service security policies by adding Security tokens on the fly while forwarding requests
  • Invoke backend .NET services using WS-Addressing

Routing Configuration

  • Configure Endpoint Routing
    • Straight Trhough Routing
      • Predefined
      • Points to the defined native endpoint
    • Content-based Routing
      • Introspect message through XPath expression
    • Conditional Routing
      • Routing decisions through context information
    • Load balanced Routing
      • Automatic Endpoint Failover/Retry
    • Dynamic Routing
      • Routing decision based on HTTP header or context information
  • Configure Custom HTTP Header
  • Configure Outbound Authentication Transport/Message SOAP only
  • Configure JMS/AMQP Routing and Properties

Predefined HTTP(S) Routing - Straight Through Routing

  • Default Routing policy for a new API
  • Different configuration for SOAP, REST backend services HTPP Method
    when CUSTOM selected, HTTP method from the incoming request is sent to native service.
    if another method are selected, the selected based is use in the request sent to the native service

Route to Different Services - Content-based Routing

If you have native service that hosted on two or more endpoint
you can use Content-based Routing to route specific type messages to specific endpoint. this routing is based on specific values that must be peer in the request messages.

to configure content based routing, you always define first default endpoint, in addition you click on Rules section to define one or multiple rule.
task of rule to determine the alternative endpoint.
in rules you can define one or multiple payload identifier using XPath, JSONPath, or Regular Expression which its depend on the request payload type

Route to Different Services - Conditional Routing

Go To Documentation SAG
its seem like content base routing, you can also route request to different services. so if you have two or more native service you can use this Conditional Routing to route to specific type of messages to specific endpoint. to configure that you first must define default endpoint URI which is use if no rule mathces then you can create rule at least one. if the rule match the request can be routed to enpoint which was define in rule if no rule match the default enpoint will be use

Conditional Routing - Rule Conditions with Variables

Configure rule conditions based on predefined \

  • System Context Variables
    like ${user}, ${inboundHttpMethod},${routingMethod}
  • Custom Context Variables
    like mx:var1, PROTOCOL_HEADERS[KEY], SOAP_HEADERS[INDEX]

Route Request to Dynamic Endpoint - Dynamic Routing

Go To Documentation SAG
This policy enables API Gateway to support dynamic routing of virtual aliases based on policy configuration. The configured policies are enforced on the request sent to an API and these requests are forwarded to the dynamic endpoint based on specific criteria that you specify.

Load Balancer Routing

Got To Documentation SAG

  • Load Balancer definition: A number of Ednpoint URIs
  • Load Balancing always works based on Round-Robin
    If you have backend service two or multiple endpoints you can use load balancing option to distributed request among this endpoint unconditionaly.

Outbound Authentication - Transport

Go To Documentation SAG This is use to apply creadentials when the backend service encforce to authentication

  • Native API is protected and expects the authentication credentials to be passed through transport headers
  • Provide proper transport-level authentication credentials to access the native API

When Inbound and Outbound not configure API Gateway just act as a proxy, forward the credentials to native service

Additonal Properties \

  • Select First Authentication sheme \
  • Authentication using, subset based on Authentication sheme
    • Custom credentials
    • Delegate incoming credentials
    • Incoming HTTP basic authentication credentials
    • Incoming Kuberos credentials
    • Incoming OAuth token
    • Incoming JWT
    • Transparent
  • Additonal properties based on mode
    • Custom credentials
    • Username, Password, Domain
    • Client Principal, Client Password, ...
    • OAuht2 token
    • ...

Outbound Authentication - Message

Go To Documentation SAG

  • Native API is protected and expects the authentication credentials to be passed through the message payload
  • Policy can co-exist Outbound Authentication-Transport
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment