12.4. OpenID Connect アイデンティティープロバイダーとしての 3scale と Red Hat Single Sign-On のインテグレーション
API プロバイダーは、3scale を OpenID Connect アイデンティティープロバイダーとして Red Hat Single Sign-On (RH-SSO) と統合できます。以下の手順は、API 要求の認証に OpenID Connect を必要とする 3scale API プロダクト向けです。
この手順の一部で、Zync が RH-SSO と通信してトークンを交換するため、3scale Zync と RH-SSO との間で SSL 接続を確立します。Zync と RH-SSO との間に SSL 接続を設定しないと、トークンはリッスンしているすべてに対してオープンになります。
3scale 2.2 以降のバージョンでは、SSL_CERT_FILE 環境変数により、RH-SSO のカスタム CA 証明書がサポートされます。この変数は、証明書バンドルのローカルパスをポイントします。OpenID Connect アイデンティティープロバイダーとして 3scale と RH-SSO を統合する際に、以下の要素を次の順序で設定します。
- RH-SSO が信頼できる認証局 (CA) が発行する証明書を 使用しない 場合は、3scale Zync がカスタム CA 証明書を使用するように設定する必要があります。信頼できる CA が発行する証明書を RH-SSO が使用する場合には、この作業は必要ありません。
- 3scale クライアントを使用するように RH-SSO を設定します。
- RH-SSO と連携するように 3scale を設定します。
前提条件
RH-SSO サーバーは
HTTPS経由で利用でき、zync-queによりアクセスできる。これをテストするには、以下のようにzync-quePod 内から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"
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"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - OpenShift クラスター管理者のパーミッション。
- OpenID Connect インテグレーションを RH-SSO と設定する 3scale API プロダクト。
詳細は、以下のセクションを参照してください。
12.4.1. カスタム認証局証明書を使用する 3scale Zync の設定 リンクのコピーリンクがクリップボードにコピーされました!
信頼できる認証局 (CA) が発行する証明書を RH-SSO が使用する場合には、この作業は必要ありません。ただし、信頼できる CA が発行する証明書を RH-SSO が 使用しない 場合は、3scale Zync を設定して 3scale クライアントを使用するように RH-SSO を、RH-SSO と連携するように 3scale を設定する必要があります。
手順
-
.pem形式で CA 証明書チェーンを取得し、各証明書を個別のファイル (例:customCA1.pem、customCA2.pemなど) として保存します。 各証明書ファイルをテストし、これが有効な CA であることを確認します。以下に例を示します。
openssl x509 -in customCA1.pem -noout -text | grep "CA:"
openssl x509 -in customCA1.pem -noout -text | grep "CA:"Copy to Clipboard Copied! Toggle word wrap Toggle overflow これは
CA:TRUEまたはCA:FALSEのいずれかを出力します。各証明書ファイルで、出力をCA:TRUEにします。出力がCA:FALSEの場合には、証明書は有効な CA ではありません。以下の
cURLコマンドを使用して、各証明書ファイルを検証します。以下に例を示します。curl -v https://<secure-sso-host>/auth/realms/master --cacert customCA1.pem
curl -v https://<secure-sso-host>/auth/realms/master --cacert customCA1.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow <secure-sso-host>は、RH-SSO ホストの完全修飾ドメイン名に置き換えます。RH-SSO レルムの JSON 設定が返されるはずです。検証に失敗した場合は、証明書が正しくない可能性があります。
zync-quePod 上の/etc/pki/tls/cert.pemファイルの既存コンテンツを収集します。oc exec <zync-que-pod-id> -- cat /etc/pki/tls/cert.pem > zync.pem
oc exec <zync-que-pod-id> -- cat /etc/pki/tls/cert.pem > zync.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のように、各カスタム CA 証明書ファイルの内容を
zync.pemに追加します。cat customCA1.pem customCA2.pem ... >> zync.pem
cat customCA1.pem customCA2.pem ... >> zync.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新規ファイルを configmap オブジェクトとして
zync-quePod に割り当てます。oc create configmap zync-ca-bundle --from-file=./zync.pem oc set volume dc/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"}]}}'oc create configmap zync-ca-bundle --from-file=./zync.pem oc set volume dc/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"}]}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow これで、証明書バンドルの
zync-quePod への追加が完了しました。証明書が追加され、コンテンツが正しいことを確認します。
oc exec <zync-que-pod-id> -- cat /etc/pki/tls/zync/zync.pem
oc exec <zync-que-pod-id> -- cat /etc/pki/tls/zync/zync.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新たな CA 証明書のバンドルをポイントするように、Zync の
SSL_CERT_FILE環境変数を設定します。oc set env dc/zync-que SSL_CERT_FILE=/etc/pki/tls/zync/zync.pem
oc set env dc/zync-que SSL_CERT_FILE=/etc/pki/tls/zync/zync.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow
12.4.2. 3scale クライアントを使用する RH-SSO の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift RH-SSO ダッシュボードで、RH-SSO を 3scale クライアントを使用するように設定します。これは特殊な管理クライアントです。API コンシューマーが開発者ポータルの API をサブスクライブするたびに、3scale はこの手順で作成した RH-SSO 管理クライアントを使用して API コンシューマーアプリケーションのクライアントを作成します。
手順
- RH-SSO コンソールで、3scale クライアントの レルムを作成 するか、3scale クライアントが含まれる既存のレルムを選択します。
- 左側のナビゲーションパネルで、新しいレルムまたは選択したレルムの Clients をクリックします。
- Create をクリックして新規クライアントを作成します。
-
Client ID フィールドに、このクライアントを 3scale クライアントとして識別するのに役立つ名前 (
oidc-issuer-for-3scaleなど) を指定します。 -
Client Protocol フィールドを
openid-connectに設定します。 - 新しいクライアントを保存します。
新しいクライアントの設定で、次のように設定します。
-
Access Type を
Confidentialに設定します。 -
Standard Flow Enabled を
OFFに設定します。 -
Direct Access Grants Enabled を
OFFに設定します。 Service Accounts Enabled を
ONに設定します。この設定により、このクライアントはサービスアカウントを発行できます。- Save をクリックします。
-
Access Type を
クライアントのサービスアカウントロールを設定します。
- クライアントの Service Account Roles タブに移動します。
- Client Roles ドロップダウンリストで、realm-management をクリックします。
- Available Roles ペインで manage-clients を選択し、Add selected >> をクリックしてロールを割り当てます。
クライアントのクレデンシャルを書き留めます。
-
クライアント ID (
<client_id>) を書き留めます。 -
クライアントの Credentials タブに移動し、Secret フィールド (
<client_secret>) の値を書き留めます。
-
クライアント ID (
承認フローのテストを容易にするには、レルムにユーザーを追加します。
- ウィンドウの左側にある Users をデプロイメントします。
- Add user をクリックします。
-
ユーザー名を入力し、Email Verified を
ONに設定し、Save をクリックします。 -
Credentials タブでパスワードを設定します。両方のフィールドにパスワードを入力し、Temporary スイッチを
OFFに設定して次回ログイン時のパスワードリセットを回避します。続いて Set password をクリックします。 - ポップアップウィンドウが表示されたら、Set password をクリックします。
12.4.3. RH-SSO と連携する 3scale の設定 リンクのコピーリンクがクリップボードにコピーされました!
3scale 管理ポータルでインテグレーション設定を指定して、Red Hat Single Sign-On (RH-SSO) と連携するように 3scale を設定します。
手順
- 3scale 管理ポータルでの最上位のセレクターで Products をクリックし、OpenID Connect 認証を有効にする 3scale API プロダクトを選択します。
- [Your_product_name] > Integration > Settings の順に移動します。
Authentication で、OpenID Connect Use OpenID Connect for any OAuth 2.0 flow を選択します。
図12.3 OPENID CONNECT(OIDC)BASICS セクションを表示します。
- OpenID Connect Issuer Type フィールドで、設定が Red Hat Single Sign-On であることを確認します。
OpenID Connect Issuer フィールドに、設定された OpenID Connect アイデンティティープロバイダーの URL を入力します。この URL の形式は以下のようになります。
https://<client_id>:<client_secret>@<rhsso_host>:<rhsso_port>/auth/realms/<realm_name>
https://<client_id>:<client_secret>@<rhsso_host>:<rhsso_port>/auth/realms/<realm_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow プレースホルダーは、以前に書き留めた RH-SSO クライアントの認証情報、RH-SSO サーバーのホストおよびポート、および RH-SSO クライアントが含まれるレルムの名前に置き換えます。
注記2 つの異なる製品で同じ認証情報を使用するには、製品ごとに一意の OIDC 発行者を設定するか、同じ発行者で異なるレルムを設定する必要があります。あるいは、アプリケーションを 2 つの異なる製品に分割して、認証に同じレルムで同じ OIDC プロバイダーを使用することもできます。方法については、手順 5 と 6 を参照してください。
OIDC AUTHORIZATION FLOW で、以下から 1 つ、または複数選択します。
- 認可コードフロー: RH-SSO では標準フローです。
- インプリシットフロー
- サービスアカウントフロー: クライアントクレデンシャルフローとも呼ばれます。
直接アクセスグラントフロー: リソースオーナーパスワードクレデンシャルとも呼ばれます。
図12.4 承認フローを選択する場所を示します。
これにより、API コンシューマーが OpenID Connect アイデンティティープロバイダーから JSON Web Tokens (JWT) を取得する方法が設定されます。3scale が OpenID Connect アイデンティティープロバイダーとして RH-SSO を統合する際に、Zync は 認可コードフロー のみが有効になっている RH-SSO クライアントを作成します。このフローは、ほとんどすべてのケースについて最もセキュアで適切なフローとして推奨されます。OpenID Connect アイデンティティープロバイダーがサポートする OAuth 2.0 フロー を必ず選択してください。
- 下方向にスクロールして Update Product をクリックし、設定を保存します。
- 左側のナビゲーションパネルで Integration > Configuration をクリックします。
- 下にスクロールして Promote v.x to APIcast Staging をクリックします。
次のステップ
RH-SSO とのインテグレーションをアイデンティティープロバイダーとしてテストします。すべてがそのまま機能したら、Integration > Configuration ページに戻り、下方向にスクロールして APIcast ステージングバージョンを実稼働バージョンにプロモートします。