SupportConsoleDevelopersStart a trialContact

Chapter 3. Securing OData APIs for a virtual database by using 3scale and RH-SSO

You can integrate data virtualization with 3scale and Red Hat’s single sign-on technology to apply advanced authorization and authentication controls to the OData endpoints for your virtual database services. By using 3Scale as a gateway to your API, you ensure that only authorized users have access, and you can control the level of access a user has based on who they are (role-based access).

By default, after you create a virtual database, the OData interface to it is discoverable by the 3Scale API management system, as long as 3Scale system is defined to same cluster and namespace. Using 3scale’s API management features, you can control access to the OData API, and track usage. By further securing access to the API through SSO, you can define user roles and implement role-based access to the API endpoints. After you complete the configuration, you can control access in the virtual database at the level of the view, column, or data source.

The Red Hat SSO technology uses OpenID-Connect as the authentication mechanism to secure the API, and uses OAuth2 as the authorization mechanism. When a user logs in, 3scale negotiates authentication with the Red Hat SSO package. If the authentication succeeds, 3scale passes a security token to the OData API for verification. The OData API then reads permissions from the token and applies them to the data roles that are defined for the virtual database.

Prerequisites

  • You have installed and configured Red Hat’s single sign-on technology. For more information about how to configure SSO to secure OData APIs for a virtual database, see the Teiid OpenShift documentation.
  • You have 3scale API Management installed in the OpenShift cluster that hosts your virtual database.

  • You have configured integration between 3scale and SSO. For more information, see Configuring Red Hat Single Sign-On integration in Using the Developer Portal.

    • You have configured the Red Hat SSO technology for OpenID Connect.
    • You have created SSO security realms.
    • You have specified an Admin client ID, protocol, and access type.
    • You have assigned the realm-management and manage-clients roles.
    • You created API users and specified credentials.
    • You configured 3scale to use OpenID-Connect as the authentication mechanism and OAuth2 as the authorization mechanism.

3.1. Updating the virtual database configuration

After you finish setting up single sign-on in OpenShift, you must modify virtual database settings before you can use SSO to secure your OData APIs. You must update the following artifacts:

  • pom.xml
  • application.properties
  • Configuration map
  • deploymentconfig.yml
  • DDL file

After you update the virtual database configuration, update the 3scale configuration to complete the integration.

Prerequisites

  • You completed the SSO configuration.

3.1.1. Adding SSO dependencies to pom.xml

Prerequisites

  • You completed the configuration to integrate 3scale with SSO.

Procedure

  • Edit the pom.xml file to add the following SSO dependencies: 

    <dependency>
  <groupId>org.teiid</groupId>
  <artifactId>spring-keycloak</artifactId>
</dependency>

3.1.2. Adding SSO settings to application.properties

Update properties in the application.properties file to support integration with SSO.

Procedure

  1. Log in to the Red Hat Single Sign-On Admin Console to find the values for the following authentication properties:

    • keycloak.realm
    • keycloak.auth-server-url
    • keycloak.resource
    • keycloak.ssl-required
    • keycloak.public-client
    • keycloak.principal-attribute

  2. Open the application.properties file from src/main/resources/ and add values for the preceding properties. For example: 

    keycloak.realm = 3scale-sso
keycloak.auth-server-url = http://keycloak-staging.dev.openshiftapps.com/auth
keycloak.resource = di
keycloak.ssl-required = external
keycloak.public-client = true
keycloak.principal-attribute=preferred_username

3.1.3. Creating a configuration map

In application.properties you assign static properties that do not change between deployment environments. For settings that can change between environments, such as authentication URLs and credentials, you might want to apply different values depending on the environment. To make it easy to apply different values for environment-specific settings, you can specify their values as properties in a configuration map. In each environment in which you deploy a virtual database, use a configuration map with the same name, but vary the map contents (the authentication URL and secret) to match the environment. Then, in each environment where you deploy the virtual database, the virtual database retrieves its version of the authentication values from the map.

You run an OpenShift command to create a configuration map and add values for the following properties:

  • keycloak.auth-server-url
  • keycloak.credentials.secret

Procedure

  1. Run the following command: 

    oc create configmap my-config --from-literal=keycloak.auth-server-url=http://<keycloakURL> --from-literal=keycloak.credentials.secret=<secretValue>

    For example, 

    oc create configmap my-config --from-literal=keycloak.auth-server-url=http://keycloak-staging.dev.example.com/auth --from-literal=keycloak.credentials.secret=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

    The preceding command creates a configuration map in OpenShift with the name my-config, which you can then reference from the deployment configuration file (deploymentconfig.yml).

3.1.4. Updating SSO environment variables in the deploymentconfig.yml file

In the deploymentconfig.yml file you can specify environment variables to apply different settings in each environment where you deploy a virtual database. For example, if you are deploying a virtual database to both a staging environment and a production environment, you can specify different environment variables in each to customize the settings for that environment.

To support SSO, you must add environment variables to the deploymentconfig.yml file.

Procedure

  • From src/main/fabric8, open the deploymentconfig.yml file and add the following environment variables: 

    - name: KEYCLOAK_AUTHSERVERURL
  valueFrom:
     configMapKeyRef:
       name: <config-name>
       key: keycloak.auth-server-url
- name: KEYCLOAK_CREDENTIALS_SECRET
  valueFrom:
     configMapKeyRef:
       name: <config-name>
       key: keycloak.credentials.secret

    For example, 

    - name: KEYCLOAK_AUTHSERVERURL
  valueFrom:
     configMapKeyRef:
       name: my-config
       key: keycloak.auth-server-url
- name: KEYCLOAK_CREDENTIALS_SECRET
  valueFrom:
     configMapKeyRef:
       name: my-config
       key: keycloak.credentials.secret

    If you deploy a virtual database in multiple environments that use different realm or client settings, be sure to specify unique realm and client properties in the SSO configuration that you establish for each environment.

3.1.5. Defining user roles in the DDL file

To apply unique data roles to different users, you must define those roles in the DDL file.

Procedure

  1. Add the following lines to the DDL file in src/main/resources: 

    CREATE ROLE ReadRole WITH JAAS ROLE ReadRole;
GRANT SELECT ON TABLE "<tableName.fieldName>” TO ReadRole

    For example, 

    CREATE ROLE ReadRole WITH JAAS ROLE ReadRole;
GRANT SELECT ON TABLE "portfolio.CustomerZip" TO ReadRole

    In the preceding example, the first line creates a role with the name ReadRole. Map this role to a role with the same name that you created in the SSO configuration. The role names can be different, but for simplicity, it’s best to use the same name. The second line grants SELECT permission to the portfolio.CustomerZip View to users who are assigned the ReadRole.

    After you make changes to the project to integrate the 3scale and enable SSO, rebuild the virtual database image and deploy it to OpenShift. For information about how to build and deploy the image, see Section 2.15, “Building a data virtualization project”.

3.2. Updating the 3scale configuration

Prerequisites

  • You have configured SSO.
  • You have made updates to the virtual database service to support SSO.

Procedure

  1. Login to your 3scale admin portal and select the service for which you want to enable OpenId Connect integration with SSO.
  2. Click the APIs tab, select the virtual database service, and click the Integration link.
  3. Click edit integration settings.
  4. In the Authentication section, click OpenID Connect, and click Update Service.
  5. From the Integration & Configuration page, click the edit APIcast configuration.
  6. Click Authentication Settings to view the authentication options.
  7. In the OpenID Connect Issuer field, type your SSO client credentials and the URL of your SSO server.
  8. Click Update Staging Environment.

  9. Create a new application so that 3scale can synchronize it with SSO.

    1. Create a new Developer account. For more information, see Creating a new developer account and API credentials in the 3scale Admin Portal Guide.
    2. In the Developer account, create an application. For more information, see Set up applications.
    3. Select an application plan for the virtual database API that you want to secure. You can select an existing application plan or create a new one. For information about how to create an application plan, see How to create an application plan in the 3scale Admin Portal Guide.
    4. Record the API credentials (the client secret and client ID). These credentials become available after you configure OpenID Connect. You must supply these credentials to access the API. If no value is displayed for the client secret, click Add random key to populate the field.
    5. Specify a redirect URL. You use the redirect URL to test the integration in Postman or other REST clients.
    6. In the Redirect URL field click Edit, type a callback link, for exmaple, https://openidconnect.net/callback, and then click Update.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.