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

Red Hat simplifies transition to open source Kafka with new service registry and HTTP bridge

Red Hat continues to increase the features available for users looking to implement a 100% open source, event-driven architecture (EDA) through running Apache Kafka on Red Hat OpenShift and Red Hat Enterprise Linux. The Red Hat Integration Q4 release provides new features and capabilities, including ones aimed at simplifying usage and deployment of the AMQ streams distribution of Apache Kafka. 

Continue reading “Red Hat simplifies transition to open source Kafka with new service registry and HTTP bridge”

Share

How to secure microservices with Red Hat Single Sign-On, Fuse, and 3scale

In this article, we’ll cover microservice security concepts by using protocols such as OpenID Connect with the support of Red Hat Single Sign-On and 3scale. Working with a microservice-based architecture, user identity, and access control in a distributed, in-depth form must be carefully designed. Here, the integration of these tools will be detailed, step-by-step, in a realistic view.

This article exemplifies the use of tools that can securely run your businesses, avoiding using homemade solutions, and protecting your services by using an API gateway, preventing your applications from being exposed to the public network. The use of an API gateway also provides additional access control, monetization, and analytics.

Continue reading “How to secure microservices with Red Hat Single Sign-On, Fuse, and 3scale”

Share

Install Red Hat 3scale and configure tenants with 7 simple commands

A couple weeks ago I was faced with the challenge of installing Red Hat 3scale and configuring its tenants using solely the command line — no GUI allowed. This is a rather interesting use case, so I decided to write this article and show how to do it with just seven commands!

(By the way, I also decided to include Red Hat Single Sign-On (SSO) in the mix because I want my APIs to use OpenID Connect (OIDC) for authentication. But I’ll leave those commands to a future article.)

Continue reading “Install Red Hat 3scale and configure tenants with 7 simple commands”

Share