Scenarios to Understand Subscription Tier Throttling in WSO2 API Manager 2.0

• With the new throttling implementation, the subscription level tier quota will define the limit that particular application can access that API 

• So basically the throttling tier policy is configured for subscription level tier by : appId + apiName + version. 
• This can be defined as per request count or bandwidth. 

• If application is used by 1000 users and subscribe to a 50000 Req/Min tier, then all the subscribed 1000 users can invoke maximum of 50000 Request per minute since it does not consider the user identification in subscription level tier policy.
• With the previous throttling implementation any application user could access limit of 50000 Req/Min. 

• When configuring Subscription level tier, Burst/rate limiting is also introduced to control the maximum requests that can be sent by a particular subscriber for a given period.
• So if the burst limit is configured as 1000 Request/s, each user will be able to send only 1000 requests per second as maximum until it reaches 50000 requests for that minute.
• If there are 10 application users using subscribed using 10 different applications, each user get 50000 requests with the limitation of sending burst requests 1000 per second.

Scenario 1 – Different users using same application using their user tokens

Throttle out an API by a subscription tier when few users from same tenant invoke a particular API subscribed via the same application when quota limit is 'request count' and when there is no burst limit

Preconditions:

1. API Manager should be up and running and user1 and user2 should be signed up with subscriber permission.
2. A subscription tier should be created as below.

• Tier Name : Silver
• Request Count : 2000
• Unit Time : 1 minute
• Burst Control (Rate Limiting) : 0
• Stop on Quota Reach : Not selected
• Billing Plan : Free or Commercial
• Custom Attributes : None
• Permissions : not defined
  

3. API 1 should have been been created and published as below by a publisher,

• Subscription Tiers : Silver
• GET resource level Tier : Unlimited is set
  

4. A developer subscribe to the API1

• Application created with an Unlimited Tier. app1
• Subscribe using application with Silver
  

5. Generate production keys for the particular application app1 and retrieve consumer key and secret.
6. User1 and User2 should generate their user tokens using the consumer key and secret generated in the above step.

User1 using app1 :

User1 Token = curl -k -d "grant_type=password&username=<Username>

&password=<Password>" -H "Authorization: Basic <app1_Token>" 

https://192.168.124.1:8243/token
 

User2 using app1 :

User2 Token = curl -k -d "grant_type=password&username=<Username>

&password=<Password>" -H "Authorization: Basic <app1_Token>" 

https://192.168.124.1:8243/token

Authorization: Basic <app1_token> =
<Base64encode(consumerkey:consumer secret of app1)>

Step	Expected Result
User 1 and User 2 invoke the GET resource as below within a minute using their user token User1 : 900 using user1 token User2 : 1101 using user2 token	User who exceeds the 2000th request should be notified as throttled out.

Scenario 2 : Same user using different applications using their user tokens

Throttle out an API by a subscription tier when the same user invokes a particular API subscribed via different applications when quota limit is 'request count' and when there is no burst limit.

Preconditions:

1. API Manager should be up and running and user1 should be signed up with subscriber permission.
2. A subscription tier should be created as below.

• Tier Name : Silver
• Request Count : 2000
• Unit Time : 1 minute
• Burst Control (Rate Limiting) : 0
• Stop on Quota Reach : Not selected
• Billing Plan : Free or Commercial
• Custom Attributes : None
• Permissions : not defined
  

3. API 1 should have been been created and published as below by a publisher,

• Subscription Tiers : Silver
• GET resource level Tier : Unlimited is set
  

4. A developer subscribe to the API1 

• 2 Applications created with an Unlimited Tier. app1 and app2
• Subscribe API1 using applications (app1 and app2) with Silver
  

5. Generate production keys for the paticular applications app1 and app2 and retrieve consumer key and secret.
6. User1 should generate the user tokens using the consumer key and secret generated in the above step for both apps

User1 using app1 :

User1 Token1 = curl -k -d "grant_type=password&username=<Username>&password=<Password>"

 -H "Authorization: Basic <app1_Token>" https://192.168.124.1:8243/token
 

User1 using app2 :

User1 Token2 = curl -k -d "grant_type=password&username=<Username>&password=<Password>"

 -H "Authorization: Basic <app2_Token>" https://192.168.124.1:8243/token

Authorization: Basic <app1_token>
= <Base64encode(consumerkey:consumer secret of app1)>

Authorization: Basic <app2_token>
 = <Base64encode(consumerkey:consumer secret of app2)>

Step	Expected Result
User 1 invoke the GET resource as below within a minute using user token1 and token2 900 requests using user1 token1 1101 requests using user1 token2	User will be able to invoke successfully all the requests
User 1 invokes the GET resource as below within a minute using their user token1 and token2 2000 using user1 token1  2001 using user1 token2	When user1 invokes the 2001st request using token2, will be notified as throttled out while other requests will be successful.

Scenario 3 : Different users via different applications using their user tokens

Throttle out an API by a subscription tier when few users from same tenant invoke a particular API subscribed via different applications when quota limit is request count and when there is no burst limit.

Preconditions:

1. API Manager should be up and running and user1 and user2 should be signed up with subscriber permission.
2. A subscription tier should be created as below.

• Tier Name : Silver
• Request Count : 2000
• Unit Time : 1 minute
• Burst Control (Rate Limiting) : 0
• Stop on Quota Reach : Not selected
• Billing Plan : Free or Commercial
• Custom Attributes : None
• Permissions : not defined
  

3. API 1 should have been been created and published as below by a publisher,

• Subscription Tiers : Silver
• GET resource level Tier : Unlimited is set
  

4. A developer subscribe to the API1

• Application 1 and application 2 created with an Unlimited Tier. app1 and app2
• Subscribe using applications with Silver
  

5. Generate production keys for the paticular applications app1 and app2 for 2 different users and retrieve consumer key and secret.
6. User1 and User2 should generate their user tokens using the consumer key and secret generated in the above step.

User 1 using app1 :

User token 1 = curl -k -d "grant_type=password&username=user1&password=user1" 

-H "Authorization: Basic <app1_Token>" https://192.168.124.1:8243/token
 

User 2 using app2 :

User token 2 = curl -k -d "grant_type=password&username=user2&password=user2" 

-H "Authorization: Basic <app2_Token>" https://192.168.124.1:8243/token

Authorization: Basic <app1_Token>
 = <Base64encode(consumerkey:consumer secret of app1)>

Authorization: Basic <app2_Token>
= <Base64encode(consumerkey:consumer secret of app2)>

Step	Expected Result
User 1 and User 2 invoke the GET resource as below within a minute using their user token User1 : 900 using user1 token  User2 : 1101 using user2 token	Both users will be able to invoke successfully.
User 1 and User 2 invoke the GET resource as below within a minute using their user tokens User1 : 2000 using user1 token  User2 : 2000 using user2 token	Both users will be able to invoke successfully.
User 1 and User 2 invoke the GET resource as below within a minute using their user tokens User1 : 2001 requests using user1 token  User2 : 2001 requests using user2 token	Both users will be notified as throttled out.

Scenario 4 : Different users via same application using test access token

Throttle out an API by a subscription tier when few users from same tenant invoke a paticular API subscribed via the same application and test access token (grant_type = client credentials) when quota limit is 'request count' and when there is no burst limit

Preconditions :
1. API Manager should be up and running and user1 and user2 should be signed up with subscriber permission.
2. A subscription tier should be created as below.

• Tier Name : Silver
• Request Count : 2000
• Unit Time : 1 minute
• Burst Control (Rate Limiting) : 0
• Stop on Quota Reach : Not selected
• Billing Plan : Free or Commercial
• Custom Attributes : None
• Permissions : not defined
  

3. API 1 should have been been created and published as below by a publisher,

• Subscription Tiers : Silver
• GET resource level Tier : Unlimited is set
  

4. A developer subscribe to the API1 

• Application created with an Unlimited Tier. app1
• Subscribe using application with Silver
  

5. Generate production keys for the paticular application app1 and retrieve test access token.
6. Test access token can be retrieved via below command.

Developer generates an access token using app1 :

Test Access Token = curl -k -d "grant_type=client_credentials" 

-H "Authorization: Basic <app1_Token>" https://192.168.124.1:8243/token

Authorization: Basic <app1_token>
 = <Base64encode(consumerkey:consumer secret of app1)>

Step	Expected Result
User 1 and User 2 invoke the GET resource as below within a minute using the same test access token generated User1 : 900 requests using test access token  User2 : 1100 requests using test access token	Both users will be able to invoke successfully.
User 1 and User 2 invoke the GET resource as below within a minute using the same test access token User1 : 900 using test access token  User2 : 1101 using test access token	User who exceeds the 2000th request should be notified as throttled out.

Scenario 5: Different users via same application via user token when the burst limit is configured

Throttle out an API by a subscription tier when few users from same tenant invoke a particular API subscribed via same applications when quota limit is request count and when there is a burst limit configured.

Preconditions :

1. API Manager should be up and running and user1 and user2 should be signed up with subscriber permission.
2. A subscription tier should be created as below.

• Tier Name : Silver
• Request Count : 2000
• Unit Time : 1 hour
• Burst Control (Rate Limiting) : 100 Request/m
• Stop on Quota Reach : Not selected
• Billing Plan : Free or Commercial
• Custom Attributes : None
• Permissions : not defined
  

3. API 1 should have been been created and published as below by a publisher,

• Subscription Tiers : Silver
• GET resource level Tier : Unlimited is set
  

4. A developer subscribe to the API1 

• Application 1 created with an Unlimited Tier. app1
• Subscribe using applications with Silver
  

5. Generate production keys for the particular applications app1 and app2 for 2 different users and retrieve consumer key and secret.
6. User1 and User2 should generate their user tokens using the consumer key and secret generated in the above step.

User 1 using app1 :

User token 1 = curl -k -d "grant_type=password&username=user1&password=user1" 

-H "Authorization: Basic <app1_Token>" https://192.168.124.1:8243/token
 

User 2 using app1 :

User token 2 = curl -k -d "grant_type=password&username=user2&password=user2" 

-H "Authorization: Basic <app1_Token>" https://192.168.124.1:8243/token

Authorization: Basic <app1_Token>
 = <Base64encode(consumerkey:consumer secret of app1)>

Step	Expected Result
User1 invoke with 100 requests (a burst) within a minute using their user token	User should be able to invoke successfully
User 1 try to send a request within the same minute in step 2.	User1 will be notified as you have exceeded your quota until the next minute
User 2 invoke with 100 requests (a burst) within the same minute in step 2 using user2's user token.	User 2 will be able to invoke successfully.
User 2 invokes again within the same minute in step 2 using user2's user token	User should be notified as exceeded quota until the next minute.
User 1 and User 2 invoke the GET resource as below within an hour with below requests sticking to burst limit. (100 requests/m) User1 : 1000 requests using user1 token  User2 : 1001 requests using user2 token	User who exceeds the throttling limit by sending the 2001st request will be notified as throttled out until the next hour since it is configured as 2000 req/hr. Until that all the requests will be successfully invoked sticking to the burst limit.

Difference in API and User Level Advance Resource throttling in WSO2 API Manager 2.0

From WSO2 API Manager 2.0 throttling implementation onward 2 different throttling levels have been introduced in Resource Level throttling.

When you login to admin dashboard you can see Advance resource throttling tier configurations under throttle policies section as given in the below screenshot.

When you add a resource tier, you can select either API or resource level as below.

API Level Resource Tier

For API level policy, it is the shared quota of all applications that invoke the API.
if someone selects API Level policy then selecting resource level policy will be disabled.

So as an example if there are 2 users subscribe to the same api, the request count or bandwidth  defined to the API is applicable for both users as a shared quota. So if you have defined 10000 requests per minute both users can share that amount.

User Level Resource Tier

For User level policy, it is the quota assigned to each application that will invoke the API.
So the quota is assigned for single user who can access the particular API from multiple applications. Simply when it's user level, throttle key will be associate with user name.

So as an example if you have selected user level, and when there are 2 users subscribed to the same API, the defined count in tier will be assigned to each user. So if you have defined 10000 requests per minute, both users get 10000 requests /1 minute per each as a total of 20000 requests.

Simple explaination for URL configurations done during IS as Key Manager in WSO2 API Manager

When you configure as IS as Key Manager, this document can be refereed. The below explanations for some of the URLs given in the configuration.

In WSO2 IS Side :

Make the following changes in the api-manager.xml file you just copied.

• Change the <RevokeAPIURL> so that it points to the API Manager server. Note that if API Manager is running in distributed mode (has a separate node for the Gateway), you need to point this URL to the Gateway node. This is done so that when the token is revoked, the Gateway cache is updated as well. The port value you enter here must be the NIO port. See Default Ports of WSO2 Products for more information.

 <RevokeAPIURL>https://${GATEWAY_SERVER_HOST}:{nio/passthrough port}/revoke</RevokeAPIURL>

Why do we point to API Manager ? This is because this will call the Gateway node in API manager which points to the Key Manager

Why we point to the NIO/Passthru port ? This is because, here we will call the _RevokeAPI_.xml which is deployed in synapse folder of the Gateway. (In a distributed scenario, we point to the _RevokeAPI_.xml that resides in the Gateway worker node)

Note : So in a distributed scenario (APIM distributed scenario), In store if you call Revoke or Regenerate, store will call the key Manager/Validator and key Manager/Validator will call the gateway.

So in Store we have to configure KeyValidator/Key manager server url and in Key Manager/Validator we have to configure gateway server url (Passthru). Inside Gateway the apis will be called (NIO)

• Change the <ServerURL> occurring under the <APIGateway> (of the Key Manager/Key Validator node) section so that it points to the API Manager server. If you are using distributed mode, this needs to point to the Gateway node as well. This is done so that when the token is regenerated, the Gateway cache is updated as well. The port value you enter here must be the management transport port.

<ServerURL>https://${GATEWAY_SERVER_HOST}:{port}/services/</ServerURL>

Why we point to API Manager ? This  is because this will call the Gateway node in API manager. This is to identify the gateway node.

Why we point to servlet port ? This is because it calls the admin services.

Note : This is same like as above explained. Since IS is the Key Validator/Manager it calls the gateway.

In WSO2 APIM Side :

Open the api-manager.xml file found in the <APIM_HOME>/repository/conf directory and change the following. 

• Change the ServerURL of the AuthManager to point to IS.

  <ServerURL>https://${IS_SERVER_HOST}:{port}/services/</ServerURL>

Why IS : This is because authentication will be done via Key manager/validator

Why we point to servlet port ? This is because it calls the admin services.

• Change the ServerURL of the APIKeyManager to point to IS.

    <ServerURL>https://${IS_SERVER_HOST}:{port}/services/</ServerURL>

Why IS : This is because authentication will be done via Key manager/validator
Why we point to servlet ports : This is because it calls admin services

Usage of ports in a gateway cluster when fronted by Nginx:

GW manager : Use to publish APIs - So only the servlet ports will be used
GW worker : Use when invoking - So only the passthrough/NIO ports will be used

Note : When you configure API endpoints in gateway (Which is in synapse folder  (E.g.,     _AuthorizeAPI_.xml, _RevokeAPI_.xml, _TokenAPI_.xml), you should edit them only in gateway manager since it will depsync to workers. Otherwise it can cause issues.

How to Test JWT caching in WSO2 API Manager

How to Test JWT caching in API Manager

Before get in to this post (http://ushanib.blogspot.com/2013/03/how-to-test-values-in-oauth2-token.html) should be referred to know the steps to enable JWT token.

When you enable JWT token in a distributed set up you should enable it in publisher node and the key manager node.
This is enabled in publisher node because to change the API template accordingly.
Enable in keymanager node : To cache it in keymanager

But when you enable caching you will have to enable it only in the key manager node.

Steps:

=====

1. First you need to enable JWT token as explained in this post. 
2. To enable Caching you need to set “true” in the following parameter in the api-manager.xml in <AM_Home>/repository/conf.
   <EnableJWTCache>true</EnableJWTCache>

To Test :

======

1. First without the caching enabled you can vie the results as explained in the post mentioned.
   
   
2. Then to go to your My Application page as given in the below screenshot and edit the application name that you have subscribed to. E.g., In the above mentioned post, subscription is done to DefaultApplication. You can change the name of it as app1.
   
   
   
   
   
   
   
   
   
3. Then send a API call request and follow the steps 11 to 15 as given in this post.
   
   
4. You will see the changed app name fter decoding the encoded value as follows :

"http://wso2.org/claims/applicationname":"app1"

5. Now enable the JWT caching as given in step 2 above and edit the app name as app2 and perform the above step 3 again.

Observation :

==========

1. Once you decode, you will be able to see the application name as app1 still since the JWT caching is enabled and the app name will be taken from the cache.
   
   
2. But if you disable JWT caching and do the same steps you will be able to see the changed app name.
   
   
3. If you have enabled key manager or gateway caching with JWT caching still it will show you the cached app name. But if the JWT caching is disabled and gateway or key manager caching is enabled, you should not be able to see the app name changes since the JWT caching is disabled.

How to test the values in the OAuth2 token (authorization header) of the original client API Call request in WSO2 API Manager

The WSO2 API Manager is an on-going project with continuous improvements and enhancements introduced with each new release to address new business challenges and customer expectations. WSO2 invites users, developers and enthusiasts to get involved or get the assistance of our development teams at many different levels through online forums, mailing lists and support options. We are committed to ensure you a fulfilling user experience at any level of involvement with the WSO2 API Manager. Reference and For more information : http://docs.wso2.org/wiki/display/AM130/About+API+Manager

I hope the intended reader of this post has successfully installed WSO2 API Manager and has got an idea about using API manager, OAuth2 token, JWT, client API calls and etc. If not, please refer the documentation for installation and as a user guide.

This blog post will be useful for anyone who wants to configure and test the authorization header of the original client API call request in API manager.

Steps to follow

1. Refer the User Guide (http://dist.wso2.org/products/api-manager/1.1.1/WSO2APIManager-v1.1-GettingStarted.pdf and follow the steps to create user roles, users, an application and take it up to publishing level. 
   
   
2. Before the above step, to view the header values, refer http://docs.wso2.org/wiki/display/AM130/Configure+JSON+Web+Token+%28JWT%29+Generation#ConfigureJSONWebTokenJWTGeneration-EnableTokenGeneration and set <EnableTokenGeneration>true</EnableTokenGeneration> as true. 
   
   
3. Start the server and create an API, publish it and subscribe to it from the API Store.
   
   
4. Invoke the API and capture the outgoing message from the API Gateway.
   
   
5. To perform the above step, configure tcp mon to view the API client call request. This request should be configured to view the client call request goes from the WSO2 API Manager to respective interface.
   
   
6. Once the app is published, make a GET, POST or a PUT request call using a curl or a Jmeter script or using a REST Client (Latest API manager has its own rest client. Or can use Chrome Advanced Rest Client Application). Read more : http://docs.wso2.org/wiki/display/AM140/REST+APIs
    Token generation is explained in Step 7.
   E.g., 
   curl -v -X POST -H "Content-type: application/xml" -d @create.xml http://localhost:9280/app/1.0.0 -H "Authorization: Bearer <token> "
   curl -v -X PUT -H "Content-type: application/xml" -d @update.xml http://localhost:9280/app/1.0.0 -H "Authorization: Bearer <token>"
    
7. If you use the access the app as an application creator use the Access Token or else as a consumer, you have to follow the below steps (8-10) to generate the authorization bearer key using both Consumer key and the consumer secret in the API Store of the relevant application once you have successfully subscribed.
   Get the both keys and copy and paste on a text pad together separated by a colon as below.
   E.g.,
   <Consumer key> : <Consumer secret>
   3kaBCHnXCYX9wgS0sFV2zGWqnRQa:YGynxN1Y43LsXCOU4gjkVuwYfoUa
   
   
   
   
   
8. Then encode it to Base64 format. Refer this site to perform it. 
   http://www.base64encode.org/
   E.g., Generated key : M2thQkNIblhDWVg5d2dTMHNGVjJ6R1dxblJRYTpZR3lueE4xWTQzTHNYQ09VNGdqa1Z1d1lmb1Vh
   
   
   
   
   
   
   
9. Then using curl generate the login key. For more reference : http://docs.wso2.org/wiki/display/AM140/User+Tokens
   
   
   curl -k -d "grant_type=password&username=admin&password=admin&scope=PRODUCTION" -H "Authorization :Basic M2thQkNIblhDWVg5d2dTMHNGVjJ6R1dxblJRYTpZR3lueE4xWTQzTHNYQ09VNGdqa1Z1d1lmb1Vh, Content-Type: application/x-www-form-urlencoded" http://localhost:8280/login

Response :

{"token_type":"bearer","expires_in":3600,"refresh_token":"401b9bca56c9afff8e9f8aece86181","access_token":"c822da634acba682187f17f32e6ed9e7"}

10. Get the access token generated (E.g., c822da634acba682187f17f32e6ed9e7) and provide it for the above access token in Step 6 curl command or for the jmeter script's variable - TokenID. "Authorization: Bearer <token>" 
    
    
11. Now send a API call request using Jmeter or curl. (Step 6)
    
    
12. Observe tcp mon.
    
    
13. You will see something like below in tcpmon.
    GET http://10.100.2.115:12765/jaxrs_basic_44/services/customers/customerservice/customers/test1/123/test2 HTTP/1.1
    X-JWT-Assertion: eyJ0eXAiOiJKV1QiLCJhbGciOiJTSEEyNTZ3aXRoUlNBIiwieDV0IjoiTm1KbU9HVXhNelpsWWpNMlpEUmhOVFpsWVRBMVl6ZGhaVFJpT1dFME5XSTJNMkptT1RjMVpBPT0ifQ==.eyJpc3MiOiJ3c28yLm9yZy9wcm9kdWN0cy9hbSIsImV4cCI6MTM2MjczNDYxNjE1NywiaHR0cDovL3dzbzIub3JnL2NsYWltcy9zdWJzY3JpYmVyIjoiYXBpc3Vic2NyaWJlciIsImh0dHA6Ly93c28yLm9yZy9jbGFpbXMvYXBwbGljYXRpb25pZCI6IjYiLCJodHRwOi8vd3NvMi5vcmcvY2xhaW1zL2FwcGxpY2F0aW9ubmFtZSI6IkFhYmNkIiwiaHR0cDovL3dzbzIub3JnL2NsYWltcy9hcHBsaWNhdGlvbnRpZXIiOiJVbmxpbWl0ZWQiLCJodHRwOi8vd3NvMi5vcmcvY2xhaW1zL2FwaWNvbnRleHQiOiIvQUFBIiwiaHR0cDovL3dzbzIub3JnL2NsYWltcy92ZXJzaW9uIjoiMS4wLjAiLCJodHRwOi8vd3NvMi5vcmcvY2xhaW1zL3RpZXIiOiJVbmxpbWl0ZWQiLCJodHRwOi8vd3NvMi5vcmcvY2xhaW1zL2tleXR5cGUiOiJQUk9EVUNUSU9OIiwiaHR0cDovL3dzbzIub3JnL2NsYWltcy91c2VydHlwZSI6IkFQUExJQ0FUSU9OX1VTRVIiLCJodHRwOi8vd3NvMi5vcmcvY2xhaW1zL2VuZHVzZXIiOiJhZG1pbiJ9.Q4Q1ET1SECUT1+OT3AEkNXuUnRg3ssUnWWyOt2Us8boBwjA9AYjnKvDnMqqaOJUjRzWqGdZjoYXycTlTmqFBVdNNq+V4Ol4FMcL5zA3mat4JvYQlvhtqD/3zP0pM7SrLCPQ8uCTWWVlX/y+bUg1F1MoKUGvpmACDbgdLtRT9Btc=
    assertion: eyJ0eXAiOiJKV1QiLCJhbGciOiJTSEEyNTZ3aXRoUlNBIiwieDV0IjoiTm1KbU9HVXhNelpsWWpNMlpEUmhOVFpsWVRBMVl6ZGhaVFJpT1dFME5XSTJNMkptT1RjMVpBPT0ifQ==.eyJpc3MiOiJ3c28yLm9yZy9wcm9kdWN0cy9hbSIsImV4cCI6MTM2MjcyNDczMzc4NiwiaHR0cDovL3dzbzIub3JnL2NsYWltcy9zdWJzY3JpYmVyIjoiYWRtaW4iLCJodHRwOi8vd3NvMi5vcmcvY2xhaW1zL2FwcGxpY2F0aW9ubmFtZSI6IkRlZmF1bHRBcHBsaWNhdGlvbiIsaHR0cDovL3dzbzIub3JnL2NsYWltcy9hcGljb250ZXh0IjoiL0FBQSIsImh0dHA6Ly93c28yLm9yZy9jbGFpbXMvdmVyc2lvbiI6IjEuMC4wIiwiaHR0cDovL3dzbzIub3JnL2NsYWltcy90aWVyIjoiVW5saW1pdGVkIiwiaHR0cDovL3dzbzIub3JnL2NsYWltcy9lbmR1c2VyIjoiYWRtaW4ifQ.Q4Q1ET1SECUT1+OT3AEkNXuUnRg3ssUnWWyOt2Us8boBwjA9AYjnKvDnMqqaOJUjRzWqGdZjoYXycTlTmqFBVdNNq+V4Ol4FMcL5zA3mat4JvYQlvhtqD/3zP0pM7SrLCPQ8uCTWWVlX/y+bUg1F1MoKUGvpmACDbgdLtRT9Btc=
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Host: 10.100.2.115:12765
    Connection: Keep-Alive
    
    
14. Copy the above green colored key which in between 2 separators. (. - dots) in assertion. That is where the header values are included. Base64 decode the second part of the 'assertation' header. Note: The assertion header consists of 3 parts separated by the '.' (period) character.
    
    
15. Use this site to decode it as below and it will generate the following. Now observe the header values.
    http://www.base64decode.org/
    
    
    
    
    
    
    
    E.g.,
    {"iss":"wso2.org/products/am","exp":1362724733786,"http://wso2.org/claims/subscriber":"admin","http://wso2.org/claims/applicationname":"DefaultApplication",http://wso2.org/claims/apicontext":"/AAA","http://wso2.org/claims/version":"1.0.0","http://wso2.org/claims/tier":"Unlimited","http://wso2.org/claims/enduser":"admin"}

E.g.,

{"iss":"wso2.org/products/am","exp":1362724733786,

"http://wso2.org/claims/subscriber":"admin",

"http://wso2.org/claims/applicationname":"DefaultApplication",

"http://wso2.org/claims/apicontext":"/AAA",

"http://wso2.org/claims/version":"1.0.0",

"http://wso2.org/claims/tier":"Unlimited",

"http://wso2.org/claims/enduser":"admin"}