WSO2 API Manager 2.1.0 - Cheat Sheet

WSO2 API Manager components

• API Publisher: Used by API owners. Create, Publish and Manage API lifecycle. URL = https://localhost:9443/publisher.
• API Store (Developer Portal): Used by API users. Discover, register and subscribe to APIs. URL = https://localhost:9443/store.
• API Gateway: Used by API consumers. All the requests comes here and security, throttling enforced here. URL = https://localhost:9443/carbon .
• Key Manager: Used by API Gateway to validate subscriptions, OAuth tokens, and API invocations. Provides a token API to generate OAuth tokens that can be accessed via the Gateway. URL = https://localhost:8243/token
• Traffic Manager: Used by API Gateway to enforce throttling. Features a dynamic throttling engine (Siddhi) to process throttling policies in real-time. URL = https://localhost:9443/admin
• API Manager Analytics: Provides a host of statistical graphs, an alerting mechanism on predetermined events and a log analyzer.

API Manager component interation

WSO2 API Manager Users and Roles

• Creator: Granted permissions to create APIs using the API publisher and view APIs in API store to understand the feedback of the developed APIs
• Publisher: Granted permissions to manage the full API life-cycle from creation on wards.
• Consumer: A consumer uses the API Store to discover APIs, see the documentation and forums, and rate/comment on the APIs. Consumers subscribe to APIs to obtain API keys.
• Admin: Super user with all the above privileges and administration capabilities

Lifecycle of an API

• CREATED: API metadata is added to the API Store, but it is not visible to subscribers yet, nor deployed to the API Gateway.
• PROTOTYPED: The API is deployed and published in the API Store as a prototype. A prototyped API is usually a mock implementation made public in order to get feedback about its usability. Users can try out a prototyped API without subscribing to it.
• PUBLISHED: The API is visible in the API Store and available for subscription.
• DEPRECATED: The API is still deployed in the API Gateway (i.e., available at runtime to existing users) but not visible to subscribers. You can deprecate an API automatically when a new version of it is published.
• RETIRED: The API is unpublished from the API Gateway and deleted from the Store.
• BLOCKED: Access to the API is temporarily blocked. Runtime calls are blocked, and the API is not shown in the API Store anymore.

API Lifecycle Visibility

 

Database configuration for distributed deployment

APIM Database configurations across profiles

 

In addition to the above mentioned databases, following databases will be used based on the usage of metrics and APIM analytics respectively.

• metrics database (metrics.xml) — once you enable metrics and JDBC storage type, you need to configure the datasource configurations in metrics-datasources.xml file.
• analytics database (WSO2_ANALYTICS_EVENT_STORE_DB) — This database needs to be configured at WSO2 APIM anaytics node to store the raw events coming into it.

In a fully distributed setup, analytics needs to be configured at each node as mentioned below.

APIM Analytics database configuration

 

Supported OAuth2 and extended grant types

• Authroization Code grant — Validate application and the end user. Use authorization endpoint (URL=https://localhost:8243/authorize) to authenticate user and token endpoint (URL=https://localhost:8243/token) to request the access token.
• Password grant — Validate application and the end user (resource owner). Use token endpoint to get the access token directly by sending the username and password of the resource owner along with base64 encoded string of consumer-key:consumer-secret pair.
• Client credentials grant — Validate only the application (client). Use token endpoint to get the access token by sending the base64 encoded string of consumer-key:consumer-secret pair.
• Implicit grant — Validate application and the end user (resource owner). Use authorization endpoint to get the token by sending the client ID (only) and user is redirected to provide user credentials. Access token is included in the redirection URL as a URI fragment.
• Refresh token grant — Used to get a new access token once the existing token is expired. Use token endpoint to get the new token by sending the refresh token and base64 encoded consumer-key:consumer-secret pair.
• SAML2 extension grant — Validate application and the end user. User will be redirected to IDP to log in to the system and IDP returns a SAML response to the application (SP). Application calls the token endpoint along with SAML token (base64 URL encoded) and consumer-key:consumer-secret pair and get the access token.
• NTLM extension grant — Validate application and the end user. User needs to get an NTLM token from the running windows server and pass that along with base64 encoded consumer-key:consumer-secret pair to token endpoint and get an access token.
• Kerberos extension grant — Validate application (client). Application calls token endpoint to get access token by sending base64 encoded consumer-key:consumer-secret pair along with kerberos ticket received from KDC (Key Distribution Centre).

WSO2 API Manager throttling capabilities

How throttling is related to applications, users and back end systems

 

 

• Application -> API throttling — Subscription tiers are available when an application subscribe for an API. Burst control can be configured at subscription tiers.
• Application -> Token throttling — Different throttling levels are available per token when creating an application
• All consumers -> API/Resource throttling — Advanced throttling tiers are available at API/Resource level for all the external consumer requests
• All consumers -> All APIs throttling — Custom throttling policies are defined globally which are applicable for all APIs for all consumer requests
• API -> back end throttling — Requests going from API to a backend can be throttled with a max back end throughput

API throttling flow

 

WSO2 API manager analytics

API Analytics architecture

• Raw events are stored in WSO2_ANALYTICS_EVENT_STORE_DB database which is configured within the analytics profile.
• These events are processed using spark scripts and processed data is stored into the WSO2AM_STATS_DB database.
• Processed data will be retrieved by the API publisher and API store to showcase the API statistics
• Siddhi runtime included within the analytics component analyses the incoming events and send realtime notifications based on the conditions configured in the node.

WSO2 API manager extensions

WSO2 API Manager extension capabilites

 

 

Happy cheating with WSO2 API Manager !!!

References:

[1] WSO2 API Manager Documentation