Saturday, December 17, 2016

How to generate large number of access tokens for WSO2 API Manager

We can generate multiple access tokens and persist them to token table using following script.  With that we will generate random users and tokens. Then insert them in to access token table. At the same time we can write them to text file so JMeter can use that file to load tokens. When we have multiple tokens and users then it will cause to increase number of throttle context created in system. And it can use to generate traffic pattern which is almost same to real production traffic.

#!/bin/bash
# Use for loop
for (( c=1; c<=100000; c++ ))
do
ACCESS_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1)
AUTHZ_USER=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 6 | head -n 1)
echo INSERT INTO "apimgt.IDN_OAUTH2_ACCESS_TOKEN (ACCESS_TOKEN,REFRESH_TOKEN,ACCESS_KEY,AUTHZ_USER,USER_TYPE,TIME_CREATED,VALIDITY_PERIOD,TOKEN_SCOPE,TOKEN_STATE,TOKEN_STATE_ID) VALUES ('$ACCESS_KEY','4af2f02e6de335dfa36d98192ec2df1', 'C2aNkK1HRJfWHuF2jo64oWA1xiAa', '$AUTHZ_USER@carbon.super', 'APPLICATION_USER', '2015-04-01 09:32:46', 99999999000, 'default', 'ACTIVE', 'NONE');" >> access_token3.sql
echo $ACCESS_KEY >> keys3.txt
done

Friday, December 16, 2016

How to avoid sending allowed domain details to client in authentication failure due to domain restriction violations in WSO2 API Manager

Sometimes hackers can use this information to guess correct domain and resend request with it. Since different WSO2 users expect different error formats we let our users to configure error messages. Since this is authentication failure you can customize auth_failure_handler.xml available in /repository/deployment/server/synapse-configs/default/sequences directory of the server. There you can define any error message status codes etc. Here i will provide sample sequence to send 401 status code and simple error message to client. If need you can customize this and send any specific response, status code etc. You can use synapse configuration language and customize error message as you need.

You can add following synapse configuration to auth_failure_handler.xml available in /repository/deployment/server/synapse-configs/default/sequences directory of the server.

<sequence name="_auth_failure_handler_" xmlns="http://ws.apache.org/ns/synapse">
 <payloadFactory media-type="xml">
<format>
<am:fault xmlns:am="http://wso2.org/apimanager">
<am:code>$1</am:code>
<am:type>Status report</am:type>
<am:message>Runtime Error</am:message>
<am:description>$2</am:description>
</am:fault>
</format>
<args>
<arg evaluator="xml" expression="$ctx:ERROR_CODE"/>
<arg evaluator="xml" expression="$ctx:ERROR_MESSAGE"/>
</args>
</payloadFactory>
<property name="RESPONSE" value="true"/>
<header name="To" action="remove"/>
<property name="HTTP_SC" value="401" scope="axis2"/>
<property name="NO_ENTITY_BODY" scope="axis2" action="remove"/>
<property name="ContentType" scope="axis2" action="remove"/>
<property name="Authorization" scope="transport" action="remove"/>
<property name="Access-Control-Allow-Origin" value="*" scope="transport"/>
<property name="Host" scope="transport" action="remove"/>
<property name="Accept" scope="transport" action="remove"/>
<send/>
<drop/>
</sequence>


Then it will be deployed automatically and for domain restriction errors you will see following error.
< HTTP/1.1 401 Unauthorized
< Access-Control-Allow-Origin: *
< domain: test.com
< Content-Type: application/xml; charset=UTF-8
< Date: Fri, 16 Dec 2016 08:31:37 GMT
< Server: WSO2-PassThrough-HTTP
< Transfer-Encoding: chunked
< 
<am:fault xmlns:am="http://wso2.org/apimanager">
<am:code>0</am:code><am:type>Status report</am:type>
<am:message>Runtime Error</am:message><am:description>Unclassified Authentication Failure</am:description></am:fault>


In the backend server logs it will print correct error message as follows. So system adminstrative users can see what is the actual issue is.


[2016-12-16 14:01:37,374] ERROR - APIUtil Unauthorized client domain :null. Only "[test.com]" domains are authorized to access the API.
[2016-12-16 14:01:37,375] ERROR - AbstractKeyValidationHandler Error while validating client domain
org.wso2.carbon.apimgt.api.APIManagementException: Unauthorized client domain :null. Only "[test.com]" domains are authorized to access the API.
    at org.wso2.carbon.apimgt.impl.utils.APIUtil.checkClientDomainAuthorized(APIUtil.java:3843)
    at org.wso2.carbon.apimgt.keymgt.handlers.AbstractKeyValidationHandler.checkClientDomainAuthorized(AbstractKeyValidationHandler.java:92)

Wednesday, October 26, 2016

Swagger code generator support for Micro Services Framework For Java


WSO2 Microservices Framework for Java (MSF4J) is a lightweight high performance framework for developing & running microservices. WSO2 MSF4J is one of the highest performing lightweight Java microservices frameworks. Now swagger code generator will generate micro service skeleton from swagger definition. So you can use this project to convert your swagger definitions to micro service quickly. With this approach you can develop complete micro service within seconds from your swagger definition.

MSF4J generator uses java-msf4j as the default library

java -jar modules/swagger-codegen-cli/target/swagger-codegen-cli.jar generate \
  -i http://petstore.swagger.io/v2/swagger.json \
  -l msf4j \
  -o samples/server/petstore/msf4j

Before you build/run service replace .deploy(new PetApi()) with your actual service class name in Application.java file like .deploy(new ApisAPI()) then it will start that service. If you have multiple service classes add them in , separated manner.

    new MicroservicesRunner()
            .deploy(new PetApi())
            .start();

To Use-it : in the generated folder try mvn package for build jar, then start your server: java -jar target/micro-service-server-1.0.0.jar (Java Microservice listening on default port 8080)

Run the following command or simply go to http://127.0.0.1:8080/pet/12 from your browser:

curl http://127.0.0.1:8080/pet/12

Tuesday, October 11, 2016

Simple auto scaling logic for software scalling

Here in this post i will list sample code(not exact code but more like pseudo code) to explain how auto scaling components works. We can use this logic in scalable load balancers to take decisions based on number of requests. 

required_instances =  request_in_fly / number_of_max_requests_per_instance;
if (required_instances > current_active_instance)
{
    //This need scale up
    if(required_instances < max_allowed)
     {
       spwan_inatances( required_instances - current_active_instance );
       wait_sometime_to_activate_instances();
     }
    else{
     //Cannot handle load
    }
}
else
{
    //This is scale down decision
    if(required_instances > min_allowed)
    {
      terminate_inatances( current_active_instance - required_instances );
      wait_some_time_to_effect_termination();
    }
}

Thursday, September 29, 2016

WSO2 API Manager 2.0.0 New Throttling logic Execution Order

Here in this post i would like to discuss how throttling happens within throttle handler with newly added complex throttling for API Manager. This order is very important and we used this order to optimize run time execution. Here is the order of execution different kind of policies.

01. Blocking conditions
Blocking requests will be executed first as it's the least expensive check. All blocking conditions will be evaluated per node basis. Blocking conditions are just checks of certain conditions and we don't need to maintain counters across all gateway nodes.

02.Advanced Throttling
If request is not blocked request then we will move to API level throttling. Here we will do throttling for API level and resource level. Here always API level throttle key will be API name. That means we can control API requests per API.

03.Subscription Throttling with burst controlling
Next thing is subscription level API throttling. When you have API in store, subscribers will come there and subscribe to that API. Whenever subscription made we will make record saying user subscribed to this API using this application. So whenever API request come to API gateway we will get application id(which use to identify API uniquely) and API context + version(which we can use to identify API uniquely) to create key to do subscription level throttling. That means when subscription level throttling happens it will always count requests for API subscribed to given application.

04.Application Throttling
Application level throttling happens in application level and users can control total number of requests come to all APIs subscribed to given application. In this case counters will maintain against application user combination.

05.Custom Throttling Policies
Users are allowed to define dynamic rules according to specific use cases. This feature will be applied globally across all tenants. System administrative users should define these rules and it will be applied across all the users in the system. When you create a custom throttling policy you can define any policy you like. Users need to write a Siddhi query to address their use case. The specific combination of attributes we are checking in the policy have to be defined as the key (which is called the key template). Usually the key template will include a predefined format and a set of predefined parameters.

Please see below diagram(draw by Sam Baheerathan) to understand this flow clearly.

Screen Shot 2016-09-28 at 7.41.46 PM.png


How newly added Traffic Manager place in WSO2 API Manager distributed deployment

Here in this post i would like to add deployment diagrams for API Manager distributed deployment and how it changes after adding traffic manager to it. If you interested about complex traffic manager deployment patterns you can go through my previous blog posts. Here i will list only deployment diagrams.

Please see below distributed API Manager deployment deployment diagram.

Image result for api manager distributed deployment


Now here is how it looks after adding traffic manager instances to it.

Untitled drawing(2).jpg


How distributed deployment looks like after adding high availability for traffic manager instances.

traffic-manager-deployment-LBPublisher-failoverReciever.png

Monday, September 26, 2016

WSO2 API Manager - Custom Throttling Policies work?

Users are allowed to define dynamic rules according to specific use cases. This feature will be applied globally across all tenants. System administrative users should define these rules and it will be applied across all the users in the system. When you create a custom throttling policy you can define any policy you like. Users need to write a Siddhi query to address their use case. The specific combination of attributes we are checking in the policy have to be defined as the key (which is called the key template). Usually the key template will include a predefined format and a set of predefined parameters.
With the new throttling implementation using WSO2 Complex Event Processor as the global throttling engine, users will be able to create their own custom throttling policies by writing custom Siddhi queries. A key template can contain a combination of allowed keys separated by a colon ":" and each key should start with the "$" prefix. In WSO2 API Manager 2.0.0, users can use the following keys to create custom throttling policies.
  • apiContext,
  • apiVersion,
  • resourceKey,
  • userId,
  • appId,
  • apiTenant,
  • appTenant

Sample custom policy

FROM RequestStream
SELECT userId, ( userId == 'admin@carbon.super'  and apiKey == '/pizzashack/1.0.0:1.0.0') AS isEligible ,
str:concat('admin@carbon.super',':','/pizzashack/1.0.0:1.0.0') as throttleKey
INSERT INTO EligibilityStream;
FROM EligibilityStream[isEligible==true]#window.time(1 min)
SELECT throttleKey, (count(throttleKey) >= 5) as isThrottled group by throttleKey
INSERT ALL EVENTS into ResultStream;
As shown in the above Siddhi query, throttle key should match keytemplate format. If there is a mismatch between the Keytemplate format and throttlekey requests will not be throttled.