WSO2 API Manager 2.1.0 - Cheat Sheet

WSO2 API Manager Components

• API Store (Developer Portal): Used by API users. Discover, register and subscribe to APIs. URL = https://localhost:9443/store.
• API Publisher: Used by API owners. Create, Publish and Manage API lifecycle. URL = https://localhost:9443/publisher.
• API Publisher: Used by API owners. Create, Publish and Manage API lifecycle. URL = https://localhost:9443/publisher.
• API Gateway: Used by API consumers. All the requests come here, and security and throttling are enforced here. URL = https://localhost:9443/carbon
• Key Manager: Used by the 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.

WSO2 API Manager Users and Roles

• Publisher: Granted permissions to manage the full API lifecycle from creation onward.
• Creator: Granted permissions to create APIs using the API publisher and view APIs in the API Store to understand the feedback given on the developed APIs.
• 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 neither yet visible to subscribers, 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, the following databases will be used based on the use of metrics and APIM analytics, respectively.

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

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

• 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.
• Authorization Code grant — Validate the application and the end user. Use the authorization endpoint (URL=https://localhost:8243/authorize) to authenticate the user and the token endpoint (URL=https://localhost:8243/token) to request the access token.
• Client credentials grant — Validate only the application (client). Use the token endpoint to get the access token by sending the base64 encoded string of consumer-key:consumer-secret pair.
• Implicit grant — Validate the application and the end user (resource owner). Use the authorization endpoint to get the token by sending the client ID (only) and the user is redirected to provide user credentials. The 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 the token endpoint to get the new token by sending the refresh token and base64 encoded consumer-key:consumer-secret pair.
• SAML2 extension grant — Validate the application and the end user. The user will be redirected to IDP to log in to the system and IDP returns a SAML response to the application (SP). The application calls the token endpoint along with SAML token (base64 URL encoded) and consumer-key:consumer-secret pair and gets the access token.
• NTLM extension grant — Validate the application and the end user. The 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 the token endpoint and get an access token.
• Kerberos extension grant — Validate the application (client). The application calls the token endpoint to get an access token by sending base64 encoded consumer-key:consumer-secret pair along with the Kerberos ticket received from the KDC (Key Distribution Centre).

WSO2 API Manager Throttling Capabilities

How throttling is related to applications, users, and backend systems

• Application -> Token throttling — Different throttling levels are available per token when creating an application.
• Application -> API throttling — Subscription tiers are available when an application subscribes to an API. Burst control can be configured at subscription tiers.
• All consumers -> API/Resource throttling — Advanced throttling tiers are available at the 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 -> backend throttling — Requests going from an API to a backend can be throttled with a max backend throughput.

API throttling flow

WSO2 API Manager Analytics

• Raw events are stored in the 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 sends real-time notifications based on the conditions configured in the node.

WSO2 API Manager Extensions

WSO2 API Manager extension capabilities

Happy cheating with WSO2 API Manager!

References:

[1] WSO2 API Manager Documentation