Custom policies in Red Hat 3scale API Management, Part 1: Overview

API management platforms such as Red Hat 3scale API Management provide an API gateway as a reverse proxy between API requests and responses. In this stage, most API management platforms optimize the request-response pathway and avoid introducing complex processing and delays. Such platforms provide minimal policy enforcement such as authentication, authorization, and rate-limiting. With the proliferation of API-based integrations, however, customers are demanding more fine-tuned capabilities.

Policy frameworks are key to adding new capabilities to the API request and response lifecycle. In this series, you will learn about the Red Hat 3scale API Management policy framework and how to use it to configure custom policies in the APIcast API gateway.

Policy enforcement with 3scale API Management

APIcast is 3scale API Management’s default data-plane gateway and policy enforcement point for API requests and responses. Its core functionality is to enforce rate limits, report methods and metrics, and use the mapping paths and security specified for each API defined in the 3scale API manager.

APIcast is built on NGINX. It is a custom implementation of a reverse proxy using the OpenResty framework, with modules written in Lua. Most NGINX functionality is implemented using modules, which are controlled by directives specified in a configuration file.

APIcast enforces API configuration rules that are set in the 3scale API manager. It authenticates new requests by connecting to the service API exposed by the API manager. It also allows access to the backend API and reports usage. Figure 1 presents a high-level view of APIcast in 3scale API Management’s API request and response flow.

A diagram of APIcast in the 3scale API Management request and response flow.

Figure 1: APIcast in the 3scale API Management API request and response flow.

The default APIcast policy

A default APIcast policy interprets the standard configuration and provides API gateway functionality. The default policy acts as the API’s entry point to the gateway and must be enabled for all APIs configured in 3scale API Management. The APIcast policy ensures that API requests are handled using the rules configured in the API manager. The configuration is provided to the APIcast gateway as a JSON specification, which APIcast downloads from the 3scale API Management portal.

Each HTTP request passes through a sequence of phases. A distinct type of processing is performed on the request in each phase. Module-specific handlers can be registered in most phases, and many standard NGINX modules register their phase handlers so that they will be called at a specific stage of request processing. Phases are processed successively, and phase handlers are called once the request reaches the phase.

To customize request processing, we can register additional modules at the appropriate phase. 3scale API Management provides standard policies that are pre-built as NGINX modules and can be plugged into each service’s request.

Custom APIcast policies

In addition to the default policy, 3scale API Management provides custom policies that can be configured to each API. Using modules and configurations, these policies provide custom features for handling API requests and responses. Using custom modules makes the APIcast gateway highly customizable. It is possible to add custom processing and functionality on demand without modifying API gateway code or writing any additional code.

Note: See the chapter on APIcast policies in the 3sale API Management documentation for a list of all the standard policies that are available to be configured directly with APIcast.

Policy chaining

Policies must be placed in order of execution priority, and this placement is called policy chaining. Policy chains affect the default behavior of any combination of policies. The default APIcast policy should be part of the policy chain. If a custom policy needs to be evaluated before the APIcast policy, it must be placed before that policy in the chain. Figure 2 shows an example of the policy order as defined in the policy chain.

A diagram of the custom policy chain.

Figure 2: A custom URL-rewriting policy in the policy chain.

For example, take a scenario using a URL-rewriting policy to change the URL path from /A/B to /B. Placing the URL-rewriting policy before the APIcast policy ensures that the path is changed before gateway processing. Backend rules, mapping rules, and metrics all will be evaluated using the /B URL path.

If, on the other hand, the custom policy should be evaluated after the APIcast policy, you can reverse the order. As an example, if you wanted the mapping rules to be evaluated for /A/B, with the URL rewrite to /B applied afterward, then you would place the URL rewriting policy after the APIcast policy.

Configuring custom policies

There are two ways to add a new policy to an API. One option is to use the Policy section for each managed API in the 3scale API Management Admin Portal. All of the available policies are available to be added. If you prefer to use the Admin API, then you can provide the policy as a JSON specification, which you can upload to the service configuration using the provided REST API.

You also can copy a set of policies as part of the service configuration from one running environment to another using the 3scale Toolbox. To verify the set of policies applied to a specific API, you can download the current configuration and configuration history from the administration portal or using the provided REST API.

Check the video below for a demonstration of the policy configuration in 3scale API Management.

Conclusion

3scale API Management provides multiple options for configuring custom API policies. This article introduced the 3scale API Management policy framework, custom policies, and policy chaining. I also presented a brief example of how to configure and view policies in 3scale API Management. Future articles in this series will look at the available policies, and I will introduce the developer toolset that you can use to create your own custom policies. In the meantime, you can explore 3scale API Management by signing up for a free 3scale API Management account.

Share

Installing Red Hat OpenShift API Management

Red Hat OpenShift API Management is a new managed application service designed as an add-on to Red Hat OpenShift Dedicated. The service provides developers with a streamlined experience when developing and delivering microservices applications with an API-first approach.

OpenShift API Management was built on the success of 3scale API Management and designed to let developers easily share, secure, reuse, and discover APIs when developing applications. This article shows you how to install OpenShift API Management as an add-on to your OpenShift Dedicated cluster. As you will see, it takes less than 10 minutes to install, configure, administer, and be up and running with OpenShift API Management. Check the end of the article for the included video demonstration.

Step 1: Get OpenShift Dedicated

You will need an OpenShift Dedicated subscription to provision a cluster to run Red Hat OpenShift API Management.

Start by provisioning your cluster:

  1. Log in to your account on cloud.redhat.com/openshift.
  2. Open the Red Hat OpenShift Cluster Manager.
  3. Create a cluster by selecting Red Hat OpenShift Dedicated.
  4. Choose your cloud provider.
  5. Fill in all the cluster configuration details: Cluster names, regions, availability zones, computer nodes, node instance type, CIDR ranges (these are optional, but cannot be modified at a later date), and so on.
  6. Submit your request and wait for the cluster to be provisioned.

Step 2: Select and configure an identity provider

Once your cluster is ready, you can configure your preferred identity provider (IDP)

To start, select and configure your identity provider (IDP) from the drop-down menu. Options include GitHub, Google, OpenID, LDAP, GitLab, and other providers that support OpenID flows.

After you have configured your IDP, you will need to add at least one user to the dedicated-admins group. Click Add user within the Cluster administrative users section, then enter the username of the new dedicated-admin user.

Access levels vary per organization. Any user that requires full access should be defined as an administrator. As an administrator, you can use 3scale API Management and OpenShift’s role-based access control (RBAC) features to limit other users’ access.

Step 3: Install OpenShift API Management

The process to install OpenShift API Management is straightforward. From the cluster details page, you can navigate to the Add-ons tab and find the services available to you. Here’s the setup:

  1. Go to the Add-ons tabs on the cluster details page.
  2. Choose Red Hat OpenShift API Management and hit Install.
  3. Provide the email address for the account that will receive service-related alerts and notifications.
  4. Click Install again to allow the Operators to install and configure the service.

After installing the add-on, you can access the service via the Application Launcher menu located in the OpenShift Dedicated console’s top-right corner. The Application Launcher provides direct access to the OpenShift API Management and Red Hat single sign-on (SSO) technology service UIs.

Watch the video demonstration

Check out the following video to see the OpenShift API Management installation steps in action:

Using OpenShift API Management

There you go! Getting OpenShift API Management installed and running on your OpenShift Dedicated cluster is as simple as the steps described here. Now you can start using the service. Check out the following resources to get going:

Share

5 steps to manage your first API using Red Hat OpenShift API Management

Companies are increasingly using hosted and managed services to deliver on application modernization efforts and reduce the burden of managing cloud infrastructure. The recent release of Red Hat OpenShift API Management makes it easier than ever to get your own dedicated instance of Red Hat 3scale API Management running on Red Hat OpenShift Dedicated.

This article is for developers who want to learn how to use Red Hat’s hosted and managed services to automatically import and manage exposed APIs. We’ll deploy a Quarkus application on OpenShift Dedicated, then use OpenShift API Management to add API key security. See the end of the article for a video demonstration of the workflow described.

Prerequisites

This article assumes that you already have the following:

  • Access to a cloud.redhat.com account.
  • An existing OpenShift Dedicated cluster or the ability to deploy one.
  • Entitlements to deploy the Red Hat OpenShift API Management add-on.
  • A development environment with:

Step 1: Obtain an OpenShift Dedicated cluster

Using a hosted and managed service like OpenShift API Management makes this step straightforward. See this video guide to obtaining an OpenShift Dedicated cluster and installing the OpenShift API Management add-on. You can also find instructions in this article and in the OpenShift API Management documentation.

Once you’ve obtained your OpenShift Dedicated cluster and installed the Red Hat OpenShift API Management add-on, we can move on to the next step.

Step 2: Create a project using the OpenShift CLI

Logging into an OpenShift Dedicated cluster via the OpenShift command-line interface requires a login token and URL. You can obtain both of these by logging into the OpenShift console via a web browser and using the configured IdP. Click Copy Login Command in the dropdown menu displayed under your username in the top-right corner. Alternatively, navigate directly to https://oauth-openshift.$CLUSTER_HOSTNAME/oauth/token/request and use your web browser to obtain a valid login command.

Once you have a token, issue a login command, then create a new project:

  1. $ oc login --token=$TOKEN --server=$URL
  2. $ oc new-project my-quarkus-api

Step 3: Deploy the Quarkus application to OpenShift

The Java application you’ll deploy for this demonstration is based on the example from the Quarkus OpenAPI and Swagger UI Guide. It’s a straightforward CRUD application that supports using a REST API to modify an in-memory list of fruits. You’ll find the source code in this GitHub repository.

Our application’s codebase differs slightly from the Quarkus OpenAPI and Swagger UI Guide example. I made the following changes:

  1. Set quarkus.smallrye-openapi.store-schema-directory in application.properties.
  2. Updated .gitignore to openapi.json and openapi.yaml.
  3. Added the quarkus-openshift extension.

These modifications create a local copy of the OpenAPI spec in JSON format and include tooling that simplifies the deployment process.

Build and deploy the Quarkus application

Start by cloning the repository to your local environment:

$ git clone https://github.com/evanshortiss/rhoam-quarkus-openapi

Issue the following command to start a local development server and view the Swagger UI at http://localhost:8080/swagger-ui:

$ ./mvnw quarkus:dev

Enter this command to build and deploy the application on your OpenShift Dedicated cluster:

$ ./mvnw clean package -Dquarkus.kubernetes.deploy=true -Dquarkus.openshift.expose=true

The build progress will be streamed from the OpenShift build pod to your terminal. You can also track the build logs and status in the project’s Builds section in the OpenShift console, as shown in Figure 1.

The Builds section in the OpenShift console.

Figure 1: Viewing build logs in the OpenShift console.

Once the build and deployment process is complete, the URL to access the application will be printed in your terminal. Use this URL to verify that the application’s OpenAPI spec is available at the /openapi?format=json endpoint. It’s important to verify that the JSON response is returned. You’ll need it to import the API to 3scale API Management and automatically generate the 3scale API Management ActiveDocs. Figure 2 shows an example of the response returned by this endpoint.

The OpenAPI spec for Quarkus Fruits.

Figure 2: Viewing the OpenAPI specification in JSON format.

Step 4: Apply Service Discovery annotations

Next, we’ll import the API into 3scale API Management using its Service Discovery feature. For this step, we need to apply a specific set of annotations and labels to the service associated with the Quarkus application. The Service Discovery annotations and labels are documented here.

Use the following commands to apply the necessary annotations:

$ oc annotate svc/rhoam-openapi "discovery.3scale.net/description-path=/openapi?format=json"
$ oc annotate svc/rhoam-openapi discovery.3scale.net/port="8080"
$ oc annotate svc/rhoam-openapi discovery.3scale.net/scheme=http

Add the discovery label using the following command:

$ oc label svc/rhoam-openapi discovery.3scale.net="true"

Verify the label and annotations using:

$ oc get svc/rhoam-openapi -o yaml

The output should be similar to the sample displayed in Figure 3.

The YAML file for the Quarkus Fruits API service definition.

Figure 3: The Quarkus API Service definition in YAML format with annotations and labels.

Step 5: Use Service Discovery to import the API

At this point, you can import the Quarkus Fruits API and manage it using 3scale API Management’s Service Discovery feature. Use the OpenShift Dedicated application launcher to navigate to the 3scale API Management console. Figure 4 shows the application launcher in the top-right corner of the OpenShift Dedicated console.

The OpenShift Dedicated console and application launcher with API Management selected.

Figure 4: Using the application launcher to access 3scale API Management.

Import the API

Log in to 3scale API Management using your configured IdP, and click the New Product link on the dashboard. Perform the following steps on the New Product screen:

  1. Select Import from OpenShift (authenticate if necessary).
  2. Choose the my-quarkus-api namespace from the Namespace dropdown.
  3. Choose the rhoam-openapi service from the Name dropdown.
  4. Click the Create Product button.

Figure 5 shows the new product screen in 3scale API Management.

The 3scale API Management dialog to create a new product.

Figure 5: Creating a new product in 3scale API Management.

At this point, you should be redirected back to the 3scale API Management dashboard. If your new API isn’t listed in the APIs section after a few moments, try refreshing the page. Once the API has been imported and listed on the dashboard, expand it and click the ActiveDoc link. Select rhoam-openapi on the subsequent screen to view the live documentation that was generated from the OpenAPI specification, as shown in Figure 6.

The 3scale API Management ActiveDocs page.

Figure 6: Viewing the generated ActiveDocs in 3scale API Management.

Create an Application Plan in 3scale API Management

Next, you’ll need to configure an Application Plan to interact with the API via a protected route:

  1. Choose Product: rhoam-openapi from the top navigation bar.
  2. Select Applications > Application Plans from the menu on the left.
  3. Click the Create Application Plan link.
  4. Enter “RHOAM Test Plan” in the Name field.
  5. Enter “rhoam-test-plan” in the System name field.
  6. Click the Create Application Plan button.
  7. Click the Publish link when redirected to the Application Plans screen.

Figure 7 shows the dialog to create a new application plan in 3scale API Management.

The 'Create Application Plan' screen in 3scale API Management.

Figure 7: Creating an application plan in 3scale API Management.

Configure a developer account to use the application

Now that you’ve created an Application Plan, you’ll need to sign up a developer account to use the application. Typically, an API consumer signs up using your API Developer portal. For the purpose of this demonstration, you will manually provide the default Developer account with API access:

  1. Select Audience from the top navigation bar.
  2. Select the Developer account from the Accounts list.
  3. Click the 1 Applications link from the breadcrumb links at the top of the screen.
  4. Click the Create Application link and you’ll be directed to the New Application screen.
  5. Select RHOAM Test Plan as the Application Plan.
  6. Enter “RHOAM Test Application” in the Name field.
  7. Enter a description of the API.
  8. Click Create Application.

Once the application is created, you’ll see that an API key is listed under the API Credentials section, as shown in Figure 8. Take note of the key.

The 3scale API Management Application Details screen.

Figure 8: Creating an application for a user generates an API key.

Test the application

Use the top navigation bar to navigate back to the Quarkus API’s product page, then open the Integration > Configuration section. The Staging APIcast section should include an example cURL command for testing, as shown in Figure 9. Copy this command and add /fruits to the URL, e.g https://my-quarkus-api-3scale-staging.$CLUSTER_HOSTNAME:443/fruits?user_key=$YOUR_API_KEY

The 3scale API Management API configuration screen.

Figure 9: The example cURL command now contains a valid API key.

Issuing the cURL command or pasting the URL into a web browser returns the list of fruits from the Quarkus API. Congratulations: You’ve deployed a Quarkus-based REST API on OpenShift and protected it using Red Hat 3scale API Management.

Video demonstration: Red Hat OpenShift API Management

If you want to go over the steps in this article again, see this video guide to using Red Hat OpenShift API Management, Quarkus​, and 3scale API Management to automatically import and manage exposed APIs.

Summary and next steps

If you’ve made it this far, you have successfully:

  • Provisioned an OpenShift Dedicated cluster.
  • Installed the Red Hat OpenShift API Management add-on.
  • Deployed a Quarkus application on your OpenShift Dedicated cluster.
  • Applied custom labels and annotations to a service using the OpenShift CLI.
  • Imported the Quarkus API into 3scale API Management and protected it using API key security.

Now that you’ve learned the basics of OpenShift Dedicated and 3scale API Management, why not explore other OpenShift Dedicated and Red Hat OpenShift API Management features? Here are some ideas:

  • Familiarize yourself with the single sign-on instance that’s included with your Red Hat OpenShift API Management add-on. You could consider using Red Hat’s single sign-on (SSO) technology instead of API key security to protect routes using OpenID Connect. (SSO is accessible from the OpenShift Dedicated application launcher.)
  • Learn more about OpenShift and your cluster by following a quickstart from the OpenShift web console’s developer perspective.
  • Delete the unprotected route to the Quarkus API using the OpenShift console or CLI. This was the route you used to view the OpenAPI in JSON format.

Happy coding!

Share

OpenID Connect integration with Red Hat 3scale API Management and Okta

This article introduces you to using Red Hat 3scale API Management for OpenID Connect (OIDC) integration and compliance. Our goal is to secure an API in 3scale API Management using JSON Web Token (JWT), OIDC, and the Oauth2 Authorization Framework. We will set up the integration using Okta as our third-party OpenID Connect identity provider. An important part of the demonstration is establishing the 3scale API Management gateway’s connection with Okta.

Note: This article is not a deep dive into OIDC or Oauth2. I won’t cover the details of authentication and authorization flows. Toward the end of the article, you will see how to obtain an access token, which you will need to execute a request against a protected API.

Prerequisites

For demonstration purposes, we will use 3scale API Management and Okta as self-managed services. If you don’t have them already, begin by creating free service accounts using 3scale.net and okta.com.

Setting up the 3scale API Management OIDC integration

Our first step is to create the simplest possible REST API for integration. We’ll use the 3scale API Management platform and an API back end configured to the echo-api: https://echo-api.3scale.net:443.

As an alternative to this setup, you could try a different back end or a self-managed APIcast instance. This article showcases OIDC authentication. You can adapt different settings to the use case.

Figure 1 shows the OIDC settings in 3scale API Management.

The dialog screen to enter the 3scale API Management OIDC settings for Okta authentication.

Figure 1: Enter the 3scale API Management OIDC settings for Okta authentication.

Note that the settings include AUTHENTICATION, AUTHENTICATION SETTINGS, and OPENID CONNECT (OIDC) BASICS. The OpenID Connect issuer URL is set to an Okta custom authorization server named “default.” It is impossible to customize an Okta default authorization server, so we will use the custom server for this example.

Overview of the 3scale API Management Okta integration

So far, we have employed OpenID Connect’s .well-known/openid-configuration endpoint to connect 3scale API Management with Okta. The 3scale API Management gateway determines what it needs from the OpenID Connect issuer URL, which we’ve just defined. Before going further, let’s clarify what we want to accomplish. The diagram in Figure 2 illustrates the step-by-step process for integrating 3scale API Management and Okta.

A diagram of the 3scale API Management and Okta integration.

Figure 2: An overview of the 3scale API Management and Okta integration.

Our goal is to call a protected API resource from 3scale API Management and use Okta for the user-delegated access.  Step 1 assumes that we’ve retrieved a JSON web token from the Okta authorization server, as defined in the OIDC specification. We will experiment with the OIDC authorization flow later.

After calling the API in Step 2, 3scale API Management verifies the JSON web token in Step 3. If the token is valid, 3scale API Management dispatches the request to the server back end, which you can see in Step 4.

Verifying the client application ID is paramount for the request to be successful. In the next sections, we will look closely at the mechanics of verification.

Verify and match the JWT claim

The 3scale API Management gateway secures every request by checking its associated JSON web token for the following characteristics:

  • Integrity: Is the JWT being tampered with by a malicious user (signature check)?
  • Expiration: Is this token expired?
  • Issuer: Has it been issued by an authorization server that is known to the 3scale API Management gateway?
  • Client ID: Does the token contain a claim matching a client application ID that is known to the 3scale API Management gateway?

The next step is to match the 3scale API Management client with the correct JWT claim.

In the 3scale API Management settings, set the ClientID Token Claim field to appid, as shown in Figure 3.

The dialog to set the ClientID Token Claim.

Figure 3: Set the ClientID Token Claim to appid.

This configuration tells 3scale API Management which claim to match against a client application in its API. For this demonstration, I decided to use appid rather than the default azp claim. The Okta authorization server requires a custom claim. I also wanted to avoid the often misunderstood and misused azp claim.

Configuring Okta

Next, let’s head over to the Okta admin portal to configure the Okta authorization server and OpenID Connect application. This configuration allows a client application to request a JSON web token on behalf of a user. Recall that we’re using a custom authorization server (named default) to add the appid JWT claim. The value assigned to this claim will be the Okta client application ID.

Configure the Okta authorization server

As shown in Figure 4, we use the Authorization Servers dialog to add a new claim to the default authorization server.

The Authorization Servers dialog in Okta admin includes the option to add the appid claim to Okta's default authorization server.

Figure 4: Add the appid claim to the default authorization server.

In OpenID Connect, two tokens are usually issued in response to the authorization code flow: The ID token and the access token. We will use the access token to access the protected resource from 3scale API Management, so we only need to add the custom claim to that token type.

Create the OIDC application

While in the Okta admin portal, we’ll use the OpenID Connect sign-on method to create a new application. Figure 5 shows the dialog to create a new application integration.

The dialog to create a new application in the Okta admin portal. The OpenID Connect sign-on method is selected.

Figure 5: Select the option to create an OpenID Connect application.

Next, we use the Create OpenID Connect Integration dialog to create the application, as shown in Figure 6.  Note that we’ll use the login redirect URI to retrieve the token later as part of the authorization flow.

Use the 'Create OpenID Connect Integration' dialog to create the Okta app.

Figure 6: Create the OpenID Connect application for Okta.

After creating the OIDC application, locate the Okta-generated client ID on the Client Credentials page, shown in Figure 7. Save this value to use when we create the corresponding client application in 3scale API Management.

The Client ID generated by Okta is located on the Client Credentials page.

Figure 7: Locate the client ID on the Okta admin Client Credentials page.

Create and assign a user to the OIDC application

The last thing we’ll do in Okta is to create and assign at least one user to the application, as shown in Figure 8. This allows a valid login to execute using the OpenID Connect authorization flow.

In the Okta admin console, create and assign at least one user to the application.

Figure 8: Create and assign at least one user to the OpenID Connect application in Okta.

This completes the Okta configuration. Next, we will configure a corresponding application in 3scale API Management.

Configuring the 3scale API Management client application

The API gateway can only authorize API calls from a previously registered client application. So, our last step is to create a 3scale API Management application whose credentials match with the application we’ve just created in Okta. We only need to match the application_id (also called the client ID), because it is carried by the JWT appid claim.

As an admin user, navigate to the 3scale API Management docs. You must use 3scale API Management to create the client application and specify a user-defined application_id. Figure 9 shows the dialog to create the 3scale API Management client application.

Create the client application using the 3scale API Management gateway API.

Figure 9: Use the 3scale API Management gateway API to create a client application.

Once you have it set up with the correct parameters, you will see the new application in the listing that subscribes to the API product you are testing.

Testing the application

Now, you might wonder how to ensure that the 3scale API Management application performs correctly. In this case, we can use Postman to execute a request with a valid JWT access token from Okta. The screenshot in Figure 10 shows how to execute the authorization flow in Postman.

Using Postman to get a JWT access token from Okta.

Figure 10: Using Postman to get a JWT access token from Okta.

A login screen should pop up, followed by the successful retrieval of the ID and access tokens. Then, we can successfully retrieve the client ID and access tokens shown in Figure 11. (Note that the access token is represented using jwt.io.)

Represents the JWT access token from Okta using jwt.io

Figure 11: Retrieve the client ID and access tokens from Okta.

From here, we call the API endpoint with the JWT access token assigned to the Authorization: Bearer HTTP request header:

$ curl "https://some-example-api.xyz.gw.apicast.io" -H "Authorization: Bearer jwt-access-token-base64"

Postman can take care of the rest. The echo-api will respond when the authentication is successful.

Using Red Hat’s single sign-on technology for OIDC integration

For this demonstration, we had to create an OpenID Connect application in both Okta and 3scale API Management. The number of applications grows as you start to delegate the process of application creation to other developers. The one OIDC specification that addresses this problem is the Dynamic Client Registration specification.

At the time of this writing, 3scale API Management and Okta don’t automatically integrate. However, Red Hat’s single sign-on technology is an open-source OpenID provider that integrates seamlessly with 3scale API Management. You can use the 3scale API Management gateway and the single sign-on developer portal to drive the authorization flow. Find out more about Red Hat single sign-on tools (7.4) and its upstream community project Keycloak.

Conclusion

Thank you for taking the time to read this article and follow the demonstration. As you have seen, 3scale API Management works together with any OpenID provider in a way that is compliant with its specification. We’ve used Okta as our OpenID provider for this demonstration. I hope that breaking down the verification process and showing each party’s roles and responsibilities helped to demystify aspects of application security with JWT, OIDC, and Oauth2.

Share

New custom metrics and air gapped installation in Red Hat 3scale API Management 2.9

We continue to update the Red Hat Integration product portfolio to provide a better operational and development experience for modern cloud– and container-native applications. The Red Hat Integration 2020-Q3 release includes Red Hat 3scale API Management 2.9, which provides new features and capabilities for 3scale. Among other features, we have updated the 3scale API Management and Gateway Operators.

This article introduces the Red Hat 3scale API Management 2.9 release highlights, including air-gapped installation for 3scale on Red Hat OpenShift and new APIcast policies for custom metrics and upstream mutual Transport Layer Security (TLS).

Continue reading “New custom metrics and air gapped installation in Red Hat 3scale API Management 2.9”

Share

HTTP-based Kafka messaging with Red Hat AMQ Streams

Apache Kafka is a rock-solid, super-fast, event streaming backbone that is not only for microservices. It’s an enabler for many use cases, including activity tracking, log aggregation, stream processing, change-data capture, Internet of Things (IoT) telemetry, and more.

Red Hat AMQ Streams makes it easy to run and manage Kafka natively on Red Hat OpenShift. AMQ Streams’ upstream project, Strimzi, does the same thing for Kubernetes.

Setting up a Kafka cluster on a developer’s laptop is fast and easy, but in some environments, the client setup is harder. Kafka uses a TCP/IP-based proprietary protocol and has clients available for many different programming languages. Only the JVM client is on Kafka’s main codebase, however.

Continue reading “HTTP-based Kafka messaging with Red Hat AMQ Streams”

Share

Build and deploy a serverless app with Camel K and Red Hat OpenShift Serverless 1.5.0 Tech Preview

Red Hat OpenShift Serverless 1.5.0 (currently in tech preview) runs on Red Hat OpenShift Container Platform 4.3. It enables stateful, stateless, and serverless workloads to all operate on a single multi-cloud container platform. Apache Camel K is a lightweight integration platform that runs natively on Kubernetes. Camel K has serverless superpowers.

In this article, I will show you how to use OpenShift Serverless and Camel K to create a serverless Java application that you can scale up or down on demand.

Continue reading “Build and deploy a serverless app with Camel K and Red Hat OpenShift Serverless 1.5.0 Tech Preview”

Share

First steps with the data virtualization Operator for Red Hat OpenShift

The Red Hat Integration Q4 release adds many new features and capabilities with an increasing focus around cloud-native data integration. The features I’m most excited about are the introduction of the schema registry, the advancement of change data capture capabilities based on Debezium to technical preview, and data virtualization (technical preview) capabilities.

Data integration is a topic that has not received much attention from the cloud-native community so far, and we will cover it in more detail in future posts. Here, we jump straight into demonstrating the latest release of data virtualization (DV) capabilities on Red Hat OpenShift 4. This is a step-by-step visual tutorial describing how to create a simple virtual database using Red Hat Integration’s data virtualization Operator. By the end of the tutorial, you will learn:

  • How to deploy the DV Operator.
  • How to create a virtual database.
  • How to access the virtual database.

The steps throughout this article work on any Openshift 4.x environment with operator support, even on time- and resource-constrained environments such as the Red Hat OpenShift Interactive Learning Portal.

Continue reading “First steps with the data virtualization Operator for Red Hat OpenShift”

Share

APIs as a Product: Get started in no time

In the previous article, APIs as a Product: Get the value out of your APIs, we presented a new approach called “APIs as a Product” to maximize the value of your APIs. In this article, we show how to quickly get started with APIs as a Product using the new features of Red Hat 3scale API Management 2.7.

To showcase the power of 3scale 2.7’s new features, combined with the awesomeness of the open source communities Apicurio and Microcks, we will design two APIs as a Product and show how we can compose both products in 3scale to get the resulting API as a Product.

Let’s look at the well-known Petstore example. Imagine for a moment that the first steps of the API Design Thinking process led to this rough definition of the customer’s needs:

  • Petstore is a company selling cuddly toys online. They would like to open a marketplace to let partners resell the pets. Ideally, orders have to placed through an API so that the whole process can be automated. The partners are split over what they want:
  • One group of Petstore’s partners expressed the need to be able to discover the Petstore inventory to add items to their own catalog.
  • Other partners want to have the checkout process managed for them, from cart creation up to checkout. 
  • A last group of partners wants to do both.

In the first part of the video below, we go through the API Ideation process to design two products: One to discover the inventory, and one to place an order. Then, we’ll go through the API Prototyping step to expose our two products as live mocks.

Finally, we use the features of 3scale 2.7 to compose both products as a unique product, expose it through API Management, and gather feedback from our early adopters.

To get started with APIs as a Product, watch this video:

Note that:

  • API Ideation starts at 01:37.
  • API Prototyping starts at 08:53.
  • The API as a Product features of 3scale 2.7 are showcased at 18:46.
Share

APIs as a Product: Get the value out of your APIs

APIs continue to spread, as seen in this 2019 report from ProgrammableWeb, which shows a 30% increase over last year’s growth rate. More regulations are enforcing the use of APIs to open up companies and foster innovation. Think of the Payment Services Directive version two (PSD2), open banking, and the public sector releasing 0pen data APIs. With such an abundance of APIs, it becomes increasingly crucial to get the value out of your APIs and differentiate yourself from the growing competition. It’s time to design and manage your APIs as a Product.

Change your organization

Designing an API as a Product implies a lot of changes in the way APIs are designed and managed. It means changing your mindset from “packaging existing services” to “fulfilling customer needs.” For teams in charge of an API, this mindset implies being in charge of a product instead, and thus:

  • Focusing on customer needs rather than existing assets.
  • Managing APIs continuously rather than for a project’s lifetime.
  • Moving from finite resources to elastic computing.
  • Evolving from a central team specialized in APIs to product cross-functional teams with a variety of competencies.

In a nutshell, designing an API as a Product means:

  • Conceiving it specifically to solve a customer problem.
  • Setting shared indicators of the value delivered by the API.
  • Having a feedback loop to know what to improve.

Change your design process

Use API design thinking to design APIs as a product.

Designing APIs as a Product also means changing the way we craft APIs (by adopting API design thinking):

  1. The first step of design thinking applied to APIs is focusing on the customers. Through their eyes, what is their pain? Empathize means meeting with and listening to your potential new customers. You will discover their understanding, how they are organized, which technical ecosystem they use, etc.
  2. Then, you would synthesize your findings to define which problem they are trying to solve and identify the Job to be Done. Customers wanting to perform a transaction to buy a pet and customers willing to synchronize their pet inventory would lead to two very different Petstore APIs.
  3. Once defined, you can foster new ideas through a process known as API Ideation. During this step, you knock up different API designs to see if one stands up as a plausible solution.
  4. During the API Prototyping phase, you mock your API based on meaningful examples to end up with a working API. Other team members can give their feedback on your design attempt.
  5. The penultimate step is to get feedback on your final design from your early adopters and thus refine the business expectations for your API.
  6. Finally, you implement the actual API.

Open source communities to help you design APIs as a Product

So far, we have only spoken about organizational changes. Dedicated tools and open source communities can help you succeed in designing and managing APIs as a Product:

  • Microcks is the open source Kubernetes-native tool for API mocking and testing that helps you during the Ideation and Prototyping phases.
  • Apicurio helps you design better API contracts in a collaborative fashion. Architects, product owners, designers, and developers can work together on the API designs.
  • Red Hat 3scale API Management eases the design and management of APIs as a Product by promoting the API designs, collecting feedback, and actually managing your APIs as a Product.

In the next article, we’ll look at how the most recent version of 3scale actually helps you build APIs as a Product.

Share