Adding API Gateway Policies Now Easier With Red Hat 3scale API Management

With the June 2018 release of Red Hat 3scale API Management 2.2, adding API Gateway policies to your API management layer is easier than ever.

What is a Policy?

Red Hat 3scale API Management provides units of functionality that modify the behavior of the API Gateway without the need to implement code. These management components are know in 3scale as policies. The configuration for the bundled policies is available from the API Manager Portal, where you can define the behavior of your API integration.

The order in which the policies are executed, known as the “policy chain”, can be configured to introduce differing behavior based on the position of the policy in the chain. Adding custom headers, perform URL rewriting, enable CORS, and configurable caching are some of the most common API gateway capabilities implemented as policies.

Continue reading “Adding API Gateway Policies Now Easier With Red Hat 3scale API Management”


An API Journey: From Idea to Deployment the Agile Way–Part III

This is part III of a three-part series describing a proposed approach for an agile API lifecycle: from ideation to production deployment. If you missed it or need a refresher, please take some time to read part I and part II.

This series is coauthored with Nicolas Massé, also a Red Hatter, and it is based on our own real-life experiences from our work with the Red Hat customers we’ve met.

In part II, we discovered how ACME Inc. is taking an agile API journey for its new Beer Catalog API deployment. ACME set up modern techniques for continuously testing its API implementation within the continuous integration/continuous delivery (CI/CD) pipeline. Let’s go now to securing the exposition.

Continue reading “An API Journey: From Idea to Deployment the Agile Way–Part III”


An API Journey: From Idea to Deployment the Agile Way–Part II

This is part II of a three-part series describing a proposed approach for an agile API lifecycle from ideation to production deployment. If you missed part 1 or need a refresher, please take some time to read part I.

This series is coauthored with Nicolas Massé, also a Red Hatter, and it is based on our own real-life experiences from our work with the Red Hat customers we’ve met.

In part I, we explored how ACME Inc. is taking an agile API journey for its new Beer Catalog API, and ACME completed the API ideation, contract design, and sampling stages. Let’s go now to mocking.

Continue reading “An API Journey: From Idea to Deployment the Agile Way–Part II”


Red Hat Summit 2018: Learn how other developers are producing cloud-native applications

Want insights into how other organizations are building cloud-native applications and microservices? At Red Hat Summit 2018, developers from a number of different companies will be sharing their stories in break-out sessions, lightning talks, and birds-of-a-feather discussions.  Learn how they solved real business problems using containers, microservices, API management, integration services, and other middleware.

Join us at Red Hat Summit 2018, to hear speakers from Bell Canada, BMW, BP, Deutsche Bank, InComm, Sabre, SIA, Swiss Railways, USAA, and many more.

Session Highlights:

Continue reading “Red Hat Summit 2018: Learn how other developers are producing cloud-native applications”


Red Hat Summit 2018: Speakers on the forefront of Cloud-Native application development

May 8th – 10th at Red Hat Summit 2018 in San Francisco, you’ll get to see, hear, and meet speakers who are working on the forefront of cloud-native application development. Some are core developers working on Red Hat products or in the upstream open source communities. A number of speakers have published books on topics such as microservices and integration.  Others are working directly with developers at Red Hat customer sites helping those organizations efficiently move to cloud-native application development.   The speakers include:

Join us at Red Hat Summit 2018, to hear speakers from Red Hat, AquaSec, Bell Canada, Black Duck, Capital One, Cloudera, Deutsche Bank, F5, Facebook, Google, Microsoft, MITRE Corp., nearForm, Pixar, Sonatype, Twistlock, and many others.

Speaker Highlights:

Continue reading “Red Hat Summit 2018: Speakers on the forefront of Cloud-Native application development”


An API Journey: From Idea to Deployment the Agile Way–Part I

The goal of this series of posts is to describe a proposed approach for an agile API delivery process. It will cover not only the development part but also the design, the tests, the delivery, and the management in production. You will learn how to use mocking to speed up development and break dependencies, use the contract-first approach for defining tests that will harden your implementation, protect the exposed API through a management gateway and, finally, secure deliveries using a CI/CD pipeline.

I coauthored this series with Nicolas Massé, who is also a Red Hatter. This series is based on our own real-life experience from our work with the Red Hat customers we’ve met, as well as from my previous position as SOA architect at a large insurance company. This series is a translation of a typical use case we run during workshops or events such as APIdays.

Continue reading “An API Journey: From Idea to Deployment the Agile Way–Part I”


Red Hat Summit 2018: Develop Secure Apps and Services

Red Hat Summit 2018 will focus on modern application development. A critical part of modern application development is of course securing your applications and services. Things were challenging when you only needed to secure a single monolithic application. In a modern application landscape, you’re probably looking at building microservices and possibly exposing application services and APIs outside the boundaries of your enterprise. In order to deploy cloud-native applications and microservices you must be able to secure them. You might be faced with the challenge of securing both applications and back-end services accessed by mobile devices while using third party identity providers like social networks. Fortunately, Red Hat Summit 2018 has a number of developer-oriented sessions where you can learn how to secure your applications and services, integrate single-sign on, and manage your APIs. Session highlights include:

Continue reading “Red Hat Summit 2018: Develop Secure Apps and Services”


Unit Testing for Camel Rest DSL and Spring Boot

Hopefully by now, you know how to write your first Rest DSL Camel Route using Spring Boot.  If not, check this post first. Now that you have your route written, it’s time to write a unit test for it.  Many people find Apache Camel unit testing a big struggle to figure out.  Luckily, when using Spring Boot with the Apache Camel Rest DSL testing, a Rest Route isn’t too difficult.

Continue reading “Unit Testing for Camel Rest DSL and Spring Boot”


Writing Your First Camel Spring Boot Project With the Rest DSL

Rest services are becoming more and more popular for communication between systems.  Now that Red Hat supports the use of Red Hat JBoss Fuse with Apache Camel Spring Boot, learn how you can get started with the Rest DSL and Spring Boot.  These directions will use the camel-servlet component, although various components can be used.

Continue reading “Writing Your First Camel Spring Boot Project With the Rest DSL”


3Scale by Red Hat Integration with ForgeRock using OpenID Connect

In my last article, I wrote about how API Management and Identity Management can work together in a complementary fashion to secure and manage the services/endpoints which applications expose as APIs. In that article I covered how Red Hat 3scale API Management can be used to integrate an identity manager, in addition to providing API management functions such as rate limiting and throttling.

This article will show how to integrate ForgeRock with 3scale by Red Hat. ForgeRock is one of the popular and growing identity management companies. ForgeRock helps organizations interact securely with customers, employees, devices, and things.

For this tutorial, the following installers are used:

Below are the components:



  1. Client App sends requests to APIcast API gateway with desired request parameters.
  2. APIcast verifies the credentials with API Manager, and stores in cache if valid.
  3. APIcast sends the request to ForgeRock, where it authenticates the user and obtains end user consent/authorization.
  4. ForgeRock sends the End-User back to the Client with an id_token, and if requested, an access_token.
  5. For every API call, the JWT token is sent via APIcast to API backend where it verifies the incoming JWT with the ForgeRock public key. If valid, then proxy the call to the API backend.
  6. The backend API extracts the JWT, verifies the scope for the user, and sends back an API response to the client application.

Sequence Diagram


To complete the end-to-end integration we should set up all pieces one by one. Below are the components and the instructions.

Setting up API backend

For this demo, I will be using the echo API service hosted by 3scale by Red Hat. You can always write a service that will extract the JWT, parse the JSON payload, extract the user profile, and send back the product subscription status for that user.

Setting up API Manager

  1. Login to 3scale by Red Hat admin portal.
  2. Select the service that you want to use to enable OpenId Connect integration with ForgeRock. Click on the APIs tab, select the Service, and click on the Integration link. We are using the default Echo API:


3. Click on edit integration settings:


4. Select OpenID Connect and click on Update Service:


5. Go back to the integration page, and click on edit APIcast configuration:


6. Enter the Staging and Production base URL. We will deploy the APIcast gateway locally on docker, so name it as http://localhost:8080:


7. Finally, click on Update Staging Environment. You can also promote it to Production (optional).

8. Create an application and get the client_id and client_secret .

8.1 Go to the Developers tab and click on Developers:


8.2 Click on Application:


8.3 Click on Create Application link:


8.4 Select the Application Plan for the service and then click on Create Application:


8.5 Note down the client_id and client_secret .  We will use the Postman to test our integration so we will fill in the callback information with a fixed link. Type in ``. in the Redirect URL field. Click on the Update button.


That’s all!
Now let’s move toward the ForgeRock setup.

Setting up ForgeRock

Installation of ForgeRock is outside the scope of this tutorial. Please refer ForgeRock documentation for installation. After installing ForgeRock, make sure you are able to access the URL on

  1. Create Realm:


2. Click on Configure Oauth Provider → Configure OpenID Connect:



3. Click on Create:



4. Creating (or syncing) the 3scale by Red Hat client_id with ForgeRock.

Our lead developer, Michal Cichra, wrote a tool called Zync to synchronize all 3scale by Red Hat client_ids to IDP. So every time when an application is created (i.e client_id and client_secret  on 3scale by Red Hat), the same is automatically created on the IDP side. For this exercise, I have manually created the client_ids using the below registration. If you prefer to create the ids runtime, edit the tool with the client registration endpoint of ForgeRock. PRs are welcome.


4.1 Click on Agents → Oauth2.0/OpenID Connect Client → New:



4.2 Copy the 3scale by Red Hat client_id and client_secret from the admin portal that you created earlier. Enter Name as client_id and Password as client_secret. Click Create:

4.3 Enter Redirection URIs → and Scope → openid. Click Save:



5. Creating an End user that will Authenticate against the IDP.

5.1 Goto Realms → Subjects. Click on New:


5.2 Enter `ID: apiUser` and `password: 12345678`:


All set for ForgeRock!

Setting up APIcast API gateway

Make sure to install docker and docker-compose before executing the next commands. We will be running APIcast API gateway locally and it will accept all incoming requests from the client.

1. git clone
2. Edit the .env file per your setup
3. docker-compose up

Send Request to APIcast

  1. Send Authorize request to APIcast
GET http://localhost:8080/authorize?client_id=21657b2d&scope=openid&response_type=token id_token&nonce=1234&redirect_uri=
client_id = 3scale client id
scope = openid
response_type = token id_token
nonce = 1234
redirect_uri =
realm = internal


2. A login page is shown from Forgerock. Enter the credentials that we created earlier for End User:

Enter credentials as: apiUser / 12345678 :


Click on Allow:


An access_token and id_tokenis redirected back to the application. The id_token is the JWT token generated by the IDP.

Paste the token on website to decrypt the contents (optional):


The above token is sent to the APIcast gateway for every call. The gateway will verify the signature of JWT using the public key. If valid, the call is proxied to the API backend along with the JWT. It’s then the backend responsibility to base64 decode the JWT, extract the user profile from JSON payload, and then (depending on the profile) send back the API response. [Refer How microservices verify a JWT for in-depth details]

Request and Response from APIcast:

curl -H "Authorization: Bearer eyAidHlwIjogIkpXVCIsICJraWQiOiAiU3lsTEM2Tmp0MUtHUWt0RDlNdCswemNlUVNVPSIsICJhbGciOiAiUlMyNTYiIH0.eyAiYXRfaGFzaCI6ICJUcUd5c2dRZURsWDhIOFNHR1FjcEF3IiwgInN1YiI6ICJhcGlVc2VyIiwgImlzcyI6ICJodHRwOi8vdmJoYWxlcmEub3NlY2xvdWQuY29tOjgwODAvb3BlbmFtL29hdXRoMi9pbnRlcm5hbCIsICJ0b2tlbk5hbWUiOiAiaWRfdG9rZW4iLCAibm9uY2UiOiAiMTIzNCIsICJhdWQiOiBbICIyMTY1N2IyZCIgXSwgIm9yZy5mb3JnZXJvY2sub3BlbmlkY29ubmVjdC5vcHMiOiAiNjk2YmRlNTYtZmNiZi00ZTFkLWIzOGItYmMzNzQ4OGVhODRiIiwgImF6cCI6ICIyMTY1N2IyZCIsICJhdXRoX3RpbWUiOiAxNTE2OTE3NTQwLCAicmVhbG0iOiAiL2ludGVybmFsIiwgImV4cCI6IDE1MTY5MjEyMzUsICJ0b2tlblR5cGUiOiAiSldUVG9rZW4iLCAiaWF0IjogMTUxNjkxNzYzNSB9.SuYI1tP5uJ94y8XRc6QQClXlmuLzMFEcE1LlW_31GafXv91jg3QwbRI-1RV1XOISfWnLW7l-1eGyKZtK_P8nroLjXYs2c-HrIgTwK16FBTcM9-Gt_jzbntwN4hiLD4PbhVb562fTkdqQCA4ZlNR9QOmQUE0ZKlMSwB3b0bNSmys" http://localhost:8080/subscriptions -v
*   Trying ::1...
* Connected to localhost (::1) port 8080 (#0)
> GET /subscriptions HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.43.0
> Accept: */*
> Authorization: Bearer eyAidHlwIjogIkpXVCIsICJraWQiOiAiU3lsTEM2Tmp0MUtHUWt0RDlNdCswemNlUVNVPSIsICJhbGciOiAiUlMyNTYiIH0.eyAiYXRfaGFzaCI6ICJUcUd5c2dRZURsWDhIOFNHR1FjcEF3IiwgInN1YiI6ICJhcGlVc2VyIiwgImlzcyI6ICJodHRwOi8vdmJoYWxlcmEub3NlY2xvdWQuY29tOjgwODAvb3BlbmFtL29hdXRoMi9pbnRlcm5hbCIsICJ0b2tlbk5hbWUiOiAiaWRfdG9rZW4iLCAibm9uY2UiOiAiMTIzNCIsICJhdWQiOiBbICIyMTY1N2IyZCIgXSwgIm9yZy5mb3JnZXJvY2sub3BlbmlkY29ubmVjdC5vcHMiOiAiNjk2YmRlNTYtZmNiZi00ZTFkLWIzOGItYmMzNzQ4OGVhODRiIiwgImF6cCI6ICIyMTY1N2IyZCIsICJhdXRoX3RpbWUiOiAxNTE2OTE3NTQwLCAicmVhbG0iOiAiL2ludGVybmFsIiwgImV4cCI6IDE1MTY5MjEyMzUsICJ0b2tlblR5cGUiOiAiSldUVG9rZW4iLCAiaWF0IjogMTUxNjkxNzYzNSB9.SuYI1tP5uJ94y8XRc6QQClXlmuLzMFEcE1LlW_31GafXv91jg3QwbRI-1RV1XOISfWnLW7l-1eGyKZtK_P8nroLjXYs2c-HrIgTwK16FBTcM9-Gt_jzbntwN4hiLD4PbhVb562fTkdqQCA4ZlNR9QOmQUE0ZKlMSwB3b0bNSmys
< HTTP/1.1 200 OK
< Server: openresty/
< Date: Thu, 25 Jan 2018 22:03:31 GMT
< Content-Type: application/json
< Content-Length: 1480
< Connection: keep-alive
< Cache-control: private
< Set-Cookie: d8c1dd0e39ac4456ed39ce5889b9a5a5=e3380f4380dfce29d71b1a31cd3dd973; path=/; HttpOnly
< Vary: Origin
< X-Content-Type-Options: nosniff
  "method": "GET",
  "path": "/subscriptions",
  "args": "",
  "body": "",
  "headers": {
    "HTTP_VERSION": "HTTP/1.1",
    "HTTP_HOST": "",
    "HTTP_ACCEPT": "*/*",
    "HTTP_AUTHORIZATION": "Bearer eyAidHlwIjogIkpXVCIsICJraWQiOiAiU3lsTEM2Tmp0MUtHUWt0RDlNdCswemNlUVNVPSIsICJhbGciOiAiUlMyNTYiIH0.eyAiYXRfaGFzaCI6ICJUcUd5c2dRZURsWDhIOFNHR1FjcEF3IiwgInN1YiI6ICJhcGlVc2VyIiwgImlzcyI6ICJodHRwOi8vdmJoYWxlcmEub3NlY2xvdWQuY29tOjgwODAvb3BlbmFtL29hdXRoMi9pbnRlcm5hbCIsICJ0b2tlbk5hbWUiOiAiaWRfdG9rZW4iLCAibm9uY2UiOiAiMTIzNCIsICJhdWQiOiBbICIyMTY1N2IyZCIgXSwgIm9yZy5mb3JnZXJvY2sub3BlbmlkY29ubmVjdC5vcHMiOiAiNjk2YmRlNTYtZmNiZi00ZTFkLWIzOGItYmMzNzQ4OGVhODRiIiwgImF6cCI6ICIyMTY1N2IyZCIsICJhdXRoX3RpbWUiOiAxNTE2OTE3NTQwLCAicmVhbG0iOiAiL2ludGVybmFsIiwgImV4cCI6IDE1MTY5MjEyMzUsICJ0b2tlblR5cGUiOiAiSldUVG9rZW4iLCAiaWF0IjogMTUxNjkxNzYzNSB9.SuYI1tP5uJ94y8XRc6QQClXlmuLzMFEcE1LlW_31GafXv91jg3QwbRI-1RV1XOISfWnLW7l-1eGyKZtK_P8nroLjXYs2c-HrIgTwK16FBTcM9-Gt_jzbntwN4hiLD4PbhVb562fTkdqQCA4ZlNR9QOmQUE0ZKlMSwB3b0bNSmys",
    "HTTP_USER_AGENT": "curl/7.43.0",
    "HTTP_X_3SCALE_PROXY_SECRET_TOKEN": "secret_token_vinay_demo",
    "HTTP_X_REAL_IP": "",
    "HTTP_X_FORWARDED_PROTO": "https",
    "HTTP_FORWARDED": "for=;;proto=https"
  "uuid": "4b100977-4b31-4dc7-9b45-bf5dadb50d97"
* Connection #0 to host localhost left intact

Thanks for taking the time and reading this tutorial. In my next blog post, I will cover how to integrate 3scale by Red Hat with PingFederate using OpenID Connect.