Bookmark this page

Securing APIs with Red Hat Single Sign-on and OAuth

Objectives

After completing this section, you should be able to secure APIs by using Red Hat Single Sign-On.

Describing OIDC Authentication Workflow in Red Hat 3scale API Management

You can configure 3scale API Management to require OpenID Connect (OIDC) as an authentication mechanism for your APIs. This means that 3scale API Management verifies the following:

  • Each request contains a JSON Web Token (JWT).

  • The JWT token is cryptographically signed by the configured OIDC provider.

  • The JWT token is valid, for example not expired.

  • The JWT token contains the necessary claims, such as the authorized party (azp) or audience (aud).

When you configure OIDC integration, APIcast reads the configuration of the OIDC provider by using the https://OIDC_PROVIDER_HOST/.well-known/openid-configuration discovery endpoint. APIcast caches information required for validating JWT tokens, such as public keys and signing algorithms.

Requests to the protected API then require a valid JWT token. The following diagram provides an example of an authentication request flow:

Figure 4.8: Authentication request flow

See the references section for more information about securing your applications with Red Hat Single Sign On (RHSSO).

Integrating 3scale API Management with RHSSO

When you configure OIDC integration in your product, 3scale API Management requires that the authorized party (azp) claim in the JWT token corresponds to the API credentials that you associate with an application in your product. However, RHSSO issues JWT tokens. Consequently, 3scale API Management must synchronize application credentials with RHSSO.

Figure 4.9: Account synchronization flow

Configuring Prerequisites for Credential Synchronization

The Zync component is responsible for the credential synchronization with RHSSO. When you create a new application, the Sidekiq component schedules Zync to synchronize the data with RHSSO. Zync asynchronously communicates with RHSSO and creates the API credentials.

For the synchronization to be successful, the Zync must be able to:

  • Connect to RHSSO.

  • Authenticate in RHSSO by using credentials with permissions to create clients.

For example, on Red Hat OpenShift Container Platform, if the zync-queue pods do not trust the RHSSO TLS certificates then the communication fails.

Additionally, Zync must authenticate with RHSSO by using a confidential Service Account client with the manage-clients role. Otherwise, Zync cannot create clients in RHSSO.

See the references section for more information about implementing the prerequisite steps.

Configuring OIDC

You can configure OIDC integration for each product in your 3scale API Management installation. When you configure OIDC integration for a particular product:

  • 3scale API Management synchronizes new applications to RHSSO, provided that you configured the prerequisites.

  • Clients must authenticate by using OIDC to reach the protected APIs. Authenticating with application credentials without JWT tokens is denied.

To configure OIDC for a product, navigate to the Admin Portal, select your product, and click IntegrationSettings. Then, select the OpenID Connect Use OpenID Connect for any OAuth 2.0 flow. authentication option.

You must provide the OIDC issuer URL with the following parameters:

  • CLIENT_ID:CLIENT_SECRET: 3scale API Management uses this client to authenticate with RHSSO.

  • PROVIDER_HOST:PROVIDER_PORT: The location of your RHSSO.

  • REALM_NAME: 3scale API Management creates RHSSO clients in this realm. Additionally, you can use users from this realm to authenticate your requests.

The following URL is an example of the RHSSO issuer URL:

https://zync-client:zync-secret@keycloak-rhsso.apps.ocp4.example.com/auth/realms/example-realm
Figure 4.10: Configuring OIDC provider for a product

Configuring Advanced JWT Claim Checks

You can use the JWT Claim Check policy to configure advanced JWT claim checks. Consequently, you can secure resources and methods of your APIs by specifying additional JWT claim values that you require for a JWT token to be valid.

For example, consider the following policy:

{
  "name": "apicast.policy.jwt_claim_check",
  "configuration": {
    "error_message": "Invalid JWT check",
    "rules": [
      {
        "operations": [
          {"op": "==", "jwt_claim": "role", "jwt_claim_type": "plain", "value": "admin"}
        ],
        "combine_op":"and",
        "methods": ["GET"],
        "resource": "/resource",
        "resource_type": "plain"
      }
    ]
  }
}

For the GET /resource request, the policy enforces that the provided JWT token contains the role claim with the value admin. Other resources and methods do not require the role claim check. All resources and methods still require a valid JWT token.

The preceding example requires RHSSO to provide the role claim for some JWT tokens.

You can configure the policy check for a particular product. Click IntegrationPolicies, then click Add policy and select JWT Claim Check.

Figure 4.11: Example JWT Claim Check policy

Troubleshooting OIDC Configuration

The following list provides the most common sources of misconfiguration and errors when you integrate 3scale API Manager with RHSSO.

Zync does not synchronize clients to RHSSO

Verify that you have fulfilled the prerequisites for OIDC integration:

  • The zync component can establish connection with RHSSO.

  • The RHSSO client that you configured has sufficient permissions to create other clients.

You can check the zync-queue logs for more details. The following example shows a RHSSO client that does not have enough permissions to create other clients:

[user@host ~]$ oc logs -l threescale_component_element=zync-que
ERROR -- : "lib":"que",
"hostname":"zync-que-3-48n7z","pid":1,"thread":241980,
"event":"job_errored","job_id":162,"elapsed":0.142748975,
"error":"AbstractAdapter::InvalidResponseError:
"error"=>"insufficient_scope", "error_description"=>"Forbidden""
APIcast refuses your JWT token

APIcast can refuse your JWT token for multiple reasons. You can enable the debug logs for your APIcast, for example by using the apicast.stagingSpec.logLevel: debug operator property. Then, check the logs for more information.

The following example shows a JWT token that does not contain the audience (aud) claim on the stage APIcast:

[user@host ~]$ oc logs -l threescale_component_element=staging
2022/02/11 13:22:57 [debug] 24#24: *110 oidc.lua:191: verify(): [jwt] failed verification for token, reason: 'aud' claim is required., requestID=567ee0a6ae81864ff959c2ece9392d43
2022/02/11 13:22:57 [debug] 24#24: *110 proxy.lua:287: rewrite(): oauth failed with 'aud' claim is required., requestID=567ee0a6ae81864ff959c2ece9392d43
A front end application fails to display successful API call results

If your front end application fails to display the result of a successful API call, then you might need to configure additional policies, such as CORS. Ensure that both RHSSO as well as your APIcast implement CORS policies.

You can implement APIcast CORS checks by adding the CORS Request Handling policy to your policy chain.

 

References

For more information about securing your applications with RHSSO, refer to the Using OpenID Connect to secure applications and services chapter in the Securing Applications and Services guide at https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html-single/securing_applications_and_services_guide/index#oidc

For more information about integrating 3scale API Management and RHSSO, refer to the Integration of 3scale with Red Hat Single Sign-On chapter in the Administering the API Gateway guide at https://access.redhat.com/documentation/en-us/red_hat_3scale_api_management/2.11/html-single/administering_the_api_gateway/index#integration-threescale-rhsso_api-gateway-apicast

Revision: do240-2.11-40390f6