13.4. 3scale API Management を Red Hat single sign-on と Red Hat build of Keycloak と統合して OpenID Connect アイデンティティープロバイダーとして使用する方法


API プロバイダーとして、3scale を Red Hat single sign-on (SSO) および Red Hat build of Keycloak と統合し、OpenID Connect アイデンティティープロバイダーとして使用できます。以下の手順は、API 要求の認証に OpenID Connect を必要とする 3scale API プロダクト向けです。

この手順の一部として、Zync が Red Hat の single sign-on テクノロジーと通信してトークンを交換するために 3scale Zync と SSO または Red Hat build of Keycloak との間に SSL 接続を確立します。Zync とシングルサインオンまたは Red Hat build of Keycloak 間の SSL 接続を設定しないと、トークンは誰でもリッスンできるようになります。

3scale 2.2 以降のバージョンでは、SSL_CERT_FILE 環境変数を使用したシングルサインオン用のカスタム CA 証明書がサポートされています。この変数は、証明書バンドルのローカルパスをポイントします。3scale をシングルサインオンと Red Hat build of Keycloak と統合し、OpenID Connect アイデンティティープロバイダーとして使用するには、次の要素を次の順序で構成します。

  • SSO または Red Hat build of Keycloak が信頼できる認証局 (CA) によって発行された証明書を 使用しない 場合は、カスタム CA 証明書を使用するように 3scale Zync を設定する必要があります。シングルサインオンで信頼できる CA によって発行された証明書を使用する場合、これは必要ありません。
  • 3scale クライアントを使用するには、シングルサインオンまたは Red Hat build of Keycloak を設定します。
  • 3scale を SSO または Red Hat build of Keycloak で動作するように設定します。

前提条件

  • single sign-on サーバーは HTTPS 経由で利用でき、zync-que によりアクセスできる。これをテストするには、以下のように zync-que Pod 内から curl https://rhsso-fqdn を実行します。

    $ oc rsh -n $THREESCALE_PROJECT $(oc get pods -n $THREESCALE_PROJECT --field-selector=status.phase==Running -o name | grep zync-que) /bin/bash -c "curl -v https://<rhsso-fqdn>/auth/realms/master"
  • OpenShift クラスター管理者のパーミッション。
  • OpenID Connect インテグレーションを single sign-on と設定する 3scale API プロダクト。

詳細は、以下のセクションを参照してください。

13.4.1. カスタム認証局証明書を使用する 3scale API Management Zync の設定

SSO または Red Hat build of Keycloak が信頼できる証明機関 (CA) によって発行された証明書を使用する場合、これは必要ありません。ただし、SSO または Red Hat build of Keycloak が信頼できる CA によって発行された証明書を 使用しない 場合は、3scale クライアントを使用するようにシングルサインオンを設定する前、および 3scale がシングルサインオンで動作するように設定する前に、3scale Zync を設定する必要があります。

手順

  1. .pem 形式で CA 証明書チェーンを取得し、各証明書を個別のファイル (例: customCA1.pemcustomCA2.pem など) として保存します。
  2. 各証明書ファイルをテストし、これが有効な CA であることを確認します。以下に例を示します。

    $ openssl x509 -in customCA1.pem -noout -text | grep "CA:"

    これは CA:TRUE または CA:FALSE のいずれかを出力します。各証明書ファイルで、出力を CA:TRUE にします。出力が CA:FALSE の場合には、証明書は有効な CA ではありません。

  3. 以下の cURL コマンドを使用して、各証明書ファイルを検証します。以下に例を示します。

    $ curl -v https://<secure-sso-host>/auth/realms/master --cacert customCA1.pem

    <secure-sso-host> は、single sign-on ホストの完全修飾ドメイン名に置き換えます。

    single sign-on レルムの JSON 設定が返されるはずです。検証に失敗した場合は、証明書が正しくない可能性があります。

  4. zync-que Pod 上の /etc/pki/tls/cert.pem ファイルの既存コンテンツを収集します。

    $ oc exec <zync-que-pod-id> -- cat /etc/pki/tls/cert.pem > zync.pem
  5. 以下のように、各カスタム CA 証明書ファイルの内容を zync.pem に追加します。

    $ cat customCA1.pem customCA2.pem ... >> zync.pem
  6. 新規ファイルを configmap オブジェクトとして zync-que Pod に割り当てます。

    $ oc create configmap zync-ca-bundle --from-file=./zync.pem
    
    $ oc set volume deployment/zync-que --add --name=zync-ca-bundle --mount-path /etc/pki/tls/zync/zync.pem --sub-path zync.pem --source='{"configMap":{"name":"zync-ca-bundle","items":[{"key":"zync.pem","path":"zync.pem"}]}}'

    これで、証明書バンドルの zync-que Pod への追加が完了しました。

  7. 証明書が追加され、コンテンツが正しいことを確認します。

    $ oc exec <zync-que-pod-id> -- cat /etc/pki/tls/zync/zync.pem
  8. 新たな CA 証明書のバンドルをポイントするように、Zync の SSL_CERT_FILE 環境変数を設定します。

    $ oc set env deployment/zync-que SSL_CERT_FILE=/etc/pki/tls/zync/zync.pem
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る