3 準備

マイクロサービス対応トランザクション・マネージャ(MicroTx)のインストールを開始する前に、トランザクション・ストア、アイデンティティ・プロバイダおよびオプションでロード・バランサを設定します。

  • トランザクション・ストア: MicroTxは、トランザクション状態の永続性を確保するためにデータ・ストアを使用します。トランザクション情報の格納には、etcdクラスタまたはOracle Databaseを使用できます。
  • アイデンティティ・プロバイダ: OpenID Connect JWTトークンを使用して、MicroTxへのユーザー・アクセスを認証および認可します。
  • ロード・バランサ: オプションで、ロード・バランサを設定する場合、ロード・バランサはヘッダーベースのルーティングとmTLSをサポートする必要があります。

3.1 インストール・バンドルのダウンロード

次のステップを実行して、MicroTxインストール・バンドルをローカル・システムにダウンロードします:

  1. MicroTxインストールバンドル(.zipファイル)をhttps://www.oracle.com/database/transaction-manager-for-microservices/からダウンロードします。
  2. MicroTxインストール・バンドルを解凍します。
    unzip otmm-<version>.zip
  3. 次のコマンドを実行し、抽出されたファイルのリストを表示します。
    ls -lR otmm-<version>

次のフォルダがあります。

  • lib: このフォルダには、MicroTxライブラリ・ファイルが含まれます。MicroTxを使用してアプリケーション・マイクロサービス間のトランザクションを管理するには、アプリケーション・コードでこれらのライブラリ・ファイルを使用する必要があります。
  • otmm: このフォルダには、MicroTxイメージおよびYAMLファイルが含まれ、これを使用してMicroTxをインストールおよび構成できます。
  • samples: このフォルダには、様々なトランザクション・プロトコル(XALRAおよびTCC)のサンプル・アプリケーションのソース・コードが含まれています。サンプル・アプリケーションのソース・コードには、MicroTxライブラリも含まれています。

3.2 データ・ストアの作成

MicroTxのトランザクション表を格納するデータ・ストアを作成します。

データ・ストアとしてetcdまたはOracle Databaseを使用できます。MicroTxをインストールする前に、データ・ストアをインストールして構成する必要があります。トランザクション・コーディネータとデータ・ストアの間の通信を可能にするために必要なネットワーキング・ルールを設定してください。

Oracle Databaseの設定の詳細は、設定するデータベースに固有のドキュメントを参照してください。

データベースに表を作成するために必要な権限があることを確認してください。MicroTxをインストールすると、サービスによって必要な表がデータベースに作成されます。MicroTxには、データベースに関する特定の詳細が必要です。

3.2.1 Autonomous Databaseクライアント資格証明の取得

MicroTxでは、トランザクション情報を追跡するための永続ストアとしてOracle Databaseの使用がサポートされます。

Autonomous Databaseインスタンスを使用していない場合は、このタスクをスキップします。Autonomous Databaseインスタンスを使用している場合は、次のステップを実行してOracleクライアント資格証明(ウォレット・ファイル)を取得します:
  1. Autonomous Databaseインスタンスからウォレットをダウンロードします。共有ExadataインフラストラクチャでのOracle Autonomous Databaseの使用クライアント資格証明(ウォレット)のダウンロードに関する項を参照してください。

    ZIPファイルがローカル・マシンにダウンロードされます。ウォレット・ファイルの名前がWallet_database.zipであるとします。

  2. ウォレット・ファイルを解凍します。
    unzip Wallet_database.zip

    ファイルが1つのフォルダに抽出されます。このフォルダの名前を書き留めます。次のステップで提供する必要があります。

  3. ウォレット・ファイルを抽出したフォルダの場所を格納する構成マップを作成します。

    このステップは、KubernetesクラスタにMicroTxをデプロイする場合にのみ実行します。

    MicroTxをデプロイするネームスペースに構成マップを作成してください。

    kubectl create configmap db-wallet-configmap --from-file=/Wallet_database_folder/ -n otmm

    説明

    • db-wallet-configmapは、作成する構成マップの名前です。MicroTxをデプロイする際、values.yamlファイルにこの名前を指定するため、この名前を書き留めます。
    • Wallet_database_folderは、圧縮されたウォレット・ファイルの内容を抽出したフォルダです。
    • otmmは、MicroTxをデプロイするネームスペースです。

    これらの値を、環境に固有の値に置き換えます。

  4. Docker SwarmにMicroTxをデプロイする場合にのみ、次のステップを実行します。

    1. Oracle Databaseのデータ・ストアへの接続文字列を作成します。

      非自律型Oracle Database (資格証明ウォレットを使用しないデータベース)を使用している場合は、次の形式を使用して接続文字列を入力します:
      <publicIP>:<portNumber>/<database unique name>.<host domain name>

      たとえば、123.213.85.123:1521/CustDB_iad1vm.sub05031027070.customervcnwith.oraclevcn.comです。

    2. 前のステップで作成した接続文字列に&wallet_location=/app/Walletを追加します。たとえば:
      tcps://adb.us-ashburn-1.oraclecloud.com:1522/bfeldfxbtjvtddi_brijeshadw1_medium.adb.oraclecloud.com?retry_count=20&retry_delay=3&wallet_location=/app/Wallet

      ここで、/app/Walletは、ウォレット・ファイルをダウンロードした場所です。

      この値は後でtcs-docker-swarm.yamlファイルで指定する必要があるため、この接続文字列を書き留めます。

次に、MicroTxをインストールする環境に基づいて、DockerシークレットまたはKubernetesシークレットを作成して、Oracle Databaseログインの詳細を提供します。

3.2.2 etcdのRSA証明書の生成

トランザクション・コーディネータのYAMLファイルにetcd資格証明およびetcdエンドポイントを指定する必要があります。MicroTxは、この情報を使用して、サービスのインストール後にデータベースへの接続を確立します。

etcdをトランザクション・ストアとして使用しない場合は、このステップをスキップします。

開始する前に、次のタスクを完了してください。

  • CFSSLツールをインストールします。https://github.com/cloudflare/cfsslを参照してください。このトピックには、CFSSLツールを使用して証明書を作成するためのサンプル・コマンドが記載されています。このツールまたはその他の任意のツールを使用して、証明書を生成できます。
  • etcdデータベースをインストールして構成します。etcdデータ・ストアの作成の詳細は、https://etcd.io/docs/を参照してください。
  • セキュリティを強化するためにetcdでTLSを有効にし、トランザクション・コーディネータのYAMLファイルに証明書の詳細を指定します。
証明書を作成し、etcdエンドポイントを識別するには:
  1. ディレクトリを作成します。

    次のサンプル・コードは、cfsslという名前のディレクトリを作成します。

    mkdir cfssl
    cd cfssl

    この中にすべての証明書を作成するため、このディレクトリのパスを書き留めます。

  2. 次のコマンドを実行して、etcdデータベース・サーバーの外部IPアドレスを識別します。

    次のコマンドは、KubernetesクラスタにMicroTxをインストールする場合にのみ実行します。

    kubectl get svc

    サンプル出力

    NAME          TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)             AGE
    
    etcd          ClusterIP      None           <none>           4002/TCP,4003/TCP   5h8m
    
    etcd-client   LoadBalancer   192.0.2.83    198.51.100.1    4002:32135/TCP      5h8m
  3. 外部IPアドレスを書き留めます。
    この値を指定して、サーバー証明書を生成し、トランザクション・コーディネータのYAMLファイルにetcdエンドポイントとして指定します。
  4. 次のコマンドを実行して、認証局を初期化します。
    echo '{"CN":"CA","key":{"algo":"rsa","size":2048}}' | cfssl gencert -initca - | cfssljson -bare ca -
    
    このコマンドは、ca-key.pemca.csrおよびca.pemという3つのファイルを現在の作業ディレクトリに作成します。
  5. 次のコマンドを実行して、認証局のオプションを構成します。

    サンプル・コマンド

    echo '{"signing":{"default":{"expiry":"43800h","usages":["signing","key encipherment","server auth","client auth"]}}}' > ca-config.json

    ここで、出力はca-config.jsonファイルに書き込まれます。

    expiryおよびusagesの値を変更できます。これらの属性の詳細は、CFSSLのドキュメントを参照してください。

  6. サーバー証明書を生成します。
    1. 次のコマンドを実行して、etcdデータベース・サーバーのIPアドレスを変数ADDRESSに割り当てます。このコマンドを環境で実行する場合は、サンプル値を環境に固有の値に置き換えます。
      export ADDRESS=192.0.2.82
    2. 次のコマンドを実行して、etcdデータベース・サーバーの名前を変数NAMEに割り当てます。これは、サーバー証明書を生成するために必要なサーバー共通名(CN)です。このコマンドを環境で実行する場合は、サンプル値を環境に固有の値に置き換えます。
      export NAME=server
    3. 次のコマンドを実行して、サーバー証明書を生成します。
      echo '{"CN":"'$NAME'","hosts":[""],"key":{"algo":"rsa","size":2048}}' | cfssl gencert -config=ca-config.json -ca=ca.pem -ca-key=ca-key.pem -hostname="$ADDRESS" - | cfssljson -bare $NAME
    このコマンドは、server-key.pemserver.csrおよびserver.pemという3つのファイルを現在の作業ディレクトリに作成します。
  7. サーバー証明書に権限を追加します。このステップは、Docker SwarmにMicroTxをインストールする場合にのみ実行します。KubernetesクラスタにMicroTxをインストールする場合は、このステップをスキップします。
    sudo chmod 644 server-key.pem
    sudo chmod 644 server.pem
  8. クライアント証明書を生成します。クライアント証明書の生成中に、クライアント証明書ホストのIPアドレスを指定する必要はありません。
    1. 次のコマンドを実行して、変数NAMEに名前を割り当てます。これは、クライアント証明書を生成するために必要なサーバー共通名(CN)です。クライアント証明書を識別するための任意の値を指定できます。
      export NAME=client
    2. 次のコマンドを実行して、クライアント証明書を生成します。
      echo '{"CN":"'$NAME'","hosts":[""],"key":{"algo":"rsa","size":2048}}' | cfssl gencert -config=ca-config.json -ca=ca.pem -ca-key=ca-key.pem -hostname="$ADDRESS" - | cfssljson -bare $NAME
    このコマンドは、client-key.pemclient.csrおよびclient.pemという3つのファイルを現在の作業ディレクトリに作成します。
  9. 次のコマンドを実行して、クライアント証明書をパスワードで保護します。
    openssl rsa -passout pass:<your_password> -aes256 -in client-key.pem -out client-ekey.pem

    <your_password>をクライアントの秘密キー・ファイルのパスワードに置き換えます。次のステップで指定する必要があるため、パスワードを覚えておいてください。

    client-ekey.pemファイルは、現在の作業ディレクトリに作成されます。次のステップで、client-ekey.pemファイルおよびパスワードの内容を指定する必要があります。

  10. 任意のテキスト・エディタで、client-ekey.pemclient.pemの内容およびクライアント証明書の保護に使用したパスワードを含むJSONファイルを作成します。

    client.pemファイルにはクライアント証明書が含まれ、client-ekey.pemファイルにはキーが含まれます。

    1. certフィールドの値として、クライアント公開キー・ファイルであるclient.pemの内容をコピーします。
    2. keyフィールドの値として、クライアント秘密キー・ファイルであるclient-ekey.pemの内容をコピーします。
    3. 前のステップで指定したクライアント秘密キー・ファイルのパスワードをkeyPasswordフィールドの値として入力します。
    4. すべての改行を改行文字\nに置き換えます。
    5. 編集した値を使用してJSONファイルを作成します。次のコードは、サンプルのJSONファイルを示しています。サンプル値は、読みやすくするために省略記号(...)を使用して一部を省いています。
    {
    "cert":"-----BEGIN CERTIFICATE-----\nMIIDOjCC...\nBQAwD..jHPs=\n-----END CERTIFICATE-----",
    "key":"-----BEGIN RSA PRIVATE KEY-----\nProc-Type: 4,ENCRYPTED\nDEK-Info: AES-256-CBC,1870...\n\nNb...\n-----END RSA PRIVATE KEY-----",
    "keyPassword":"<your_password>"
    }
  11. JSONファイルを検証してから保存します。ファイルの名前とその場所を指定する必要があるため、覚えておいてください。JSONファイルをetcdecred.JSONとして保存するとします。

3.3 認証および認可について

認証によって、認可された個人のみがTransaction Manager for Microservices (MicroTx)、マイクロサービス、データにアクセスできるようになります。認可によって、システム権限およびデータへのアクセス制御が提供されます。これは認証に基づいて、個人が適切なアクセス権を取得することを保証します。

3.3.1 認証および認可について

認可トークンおよびリフレッシュ・トークンを使用して、トランザクション・イニシエータ・サービスとMicroTxの間のセキュアな通信を確保します。非同期コールをサポートするために、アクセス・トークンおよびリフレッシュ・トークンを格納します。トークン伝播を使用して、参加側サービスとMicroTxの間のセキュアな通信を確保します。

3.3.1.1 認可トークンおよびリフレッシュ・トークンについて

認可トークンおよびリフレッシュ・トークンを使用して、トランザクション・イニシエータ・サービスとMicroTxの間のセキュアな通信を確保します。認可トークンおよびリフレッシュ・トークンを作成するにはアイデンティティ・プロバイダを使用します。新しいREST APIリクエスト(旅行を予約するリクエストなど)を送信するときに、リクエスト・ヘッダーで認可トークンとリフレッシュ・トークンも渡す必要があります。

認可トークン

認証を有効にする際には、すべてのリクエストのauthorizationヘッダーでアクセス・トークンを渡す必要があります。MicroTxは、JWTベースの認証を強制し、すべての受信リクエストの認証トークンを公開キーに対して検証します。また、MicroTxライブラリからトランザクション・コーディネータに送信されたすべてのコールも検証されます。MicroTxは、認可トークンを渡すユーザーに、操作を実行するために必要なシステム権限があることを確認します。これにより、検証されたユーザーのみがMicroTx APIにアクセスできるようになります。

YAMLファイルで認可を有効にしたときでも、リクエストの送信時に認可トークンを指定しない場合は、認可トークンがないためトランザクションは拒否されます。

リフレッシュ・トークン

リフレッシュ・トークンを使用して、期限切れのアクセス・トークンをリフレッシュします。非同期のコールまたはトランザクションは、数分または数時間にわたる可能性があります。たとえば、LRAトランザクション・プロトコルを使用して、ホテルと航空券を予約するとします。ユーザーが予約を完了するまでに数分かかる場合があります。しかしながら、ユーザーがトランザクションを完了する前に、認証トークンが期限切れになる可能性があります。YAMLファイルでアイデンティティ・プロバイダのURLおよびクライアントIDを指定すると、MicroTxはリフレッシュ・トークンをアイデンティティ・プロバイダに提供し、新しいアクセス・トークンを取得します。

3.3.1.2 Oracle_Tmm_Tx_Tokenトランザクション・トークンについて

トランザクション・トークンの作成と伝播を有効にして、参加側サービスとMicroTxの間のセキュアな通信を確保します。YAMLファイルでtransactionTokenEnabledtrueに設定すると、MicroTxは、署名付きトランザクション・トークンであるOracle_Tmm_Tx_Tokenという新しいトークンを作成します。

次のステップで、MicroTxOracle_Tmm_Tx_Tokenトランザクション・トークンを作成し、参加側サービスとMicroTxの間の後続の通信でそのトークンを伝播する方法を説明します。

  1. ユーザーがトランザクションを開始すると、トランザクション・イニシエータ・サービスがMicroTxにリクエストを送信します。
  2. MicroTxはトランザクション・イニシエータに応答し、レスポンス・ヘッダーでOracle_Tmm_Tx_Tokenを返します。

    MicroTxライブラリは、指定した秘密キーと公開キーのペアに基づいてこのトークンを作成します。ユーザーがOracle_Tmm_Tx_Tokenトランザクションを作成したり、リクエスト・ヘッダーで渡したりする必要はありません。

    MicroTxは、複数のヘッダーおよびトークンを使用して動作します。わかりやすくするために、この項ではOracle_Tmm_Tx_Tokenトランザクション・トークンについてのみ説明します。

  3. 参加側サービスからトランザクション・コーディネータへのコールを保護するため、MicroTxライブラリは、後続のすべてのコールのリクエスト・ヘッダーにOracle_Tmm_Tx_Tokenを渡します。

Kubernetesクラスタでのトランザクション・トークンの伝播を有効にするには、「トランザクション・トークンのプロパティ」を参照してください。

Docker Swarmでのトランザクション・トークンの伝播を有効にするには、「トランザクション・トークンのプロパティ」を参照してください。

3.3.1.3 トークンの暗号化および格納について

非同期コールをサポートするために、MicroTxは認可トークンとリフレッシュ・トークンを格納してから、非同期コールで使用します。

トークンを格納するには、トークンを暗号化する必要があります。トークンを直接格納することはできないためです。トークンを暗号化するには、暗号化キーを作成します。MicroTxはトークンを暗号化して格納します。MicroTxから参加側サービスへの非同期コールがある場合、MicroTxは暗号化されたトークンをフェッチし、それを復号化してから、トークンをリクエスト・ヘッダーに添付します。

MicroTxは、アクセス・トークンおよびリフレッシュ・トークンを暗号化し、後で参加側サービスへのコール時に使用します。MicroTxは、トランザクションごとに初期化ベクトルの新しい値を生成します。各トランザクション・レコードには、キー・バージョンや初期化ベクトル値などの暗号化されたメタデータ情報が含まれます。

3.3.2 Oracleアイデンティティ・プロバイダの使用

Oracle Identity Cloud Service (IDCS)またはOracle IAMをアイデンティティ・プロバイダとして使用し、アプリケーションへのアクセスを管理できます。

KeycloakまたはMicrosoft ADをアイデンティティ・プロバイダとして使用する場合は、アイデンティティ・プロバイダの設定およびアクセス・トークンの作成の詳細について製品ドキュメントを参照してください。

Oracle Cloud Infrastructureでは、以前はOracle IDCSがアイデンティティ・プロバイダとして使用されていました。現在、Oracle Cloud Infrastructureでは、アイデンティティ・プロバイダとしてOracle IAMが使用されます。

ご使用のOracle Cloud InfrastructureテナンシでOracle IDCSとOracle IAMのどちらが使用されているかを識別するには:
  1. Oracle Cloud Infrastructureコンソールにログインします。
  2. ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。
    • 「アイデンティティ」「ユーザーおよびグループ」が表示されている場合、テナンシはOracle IAMに移行されていません。テナンシではOracle IDCSが使用されています。
    • 「アイデンティティ」「ドメイン」が表示されている場合、テナンシはOracle IAMに移行されています。
テナンシでOracle IDCSとOracle IAMのどちらが使用されているかに基づいて、関連情報を使用し、機密アプリケーションを作成してアクティブ化できます。
3.3.2.1 アイデンティティ・プロバイダとしてのOracle IAMの使用

Oracle IAMをアイデンティティ・プロバイダとして使用し、アプリケーションへのアクセスを管理できます。

  1. Oracle Cloud Infrastructureコンソールで、アプリケーションを機密アプリケーションとして追加します。Oracle Cloud Infrastructureドキュメント機密アプリケーションの追加を参照してください。
    「OAuthの構成」ペインで選択されているオプション

    機密アプリケーションを追加する際に、次のタスクを実行します:

    1. 「OAuthの構成」ペインの「リソース・サーバー構成」で、「後にスキップ」をクリックします。
    2. 「OAuthの構成」ペインで、「このアプリケーションをクライアントとして今すぐ構成します」をクリックし、次のオプションを選択します:
      • リソース所有者
      • クライアント資格証明
      • JWTアサーション
      • リフレッシュ・トークン
      • 認可コード
      • HTTPSのURLを許可: オプション。HTTPSなしのリダイレクトURLを追加する場合のみ、このオプションを選択します。このオプションを選択しない場合、HTTPS URLのみがサポートされます。
      • リダイレクトURLの追加: 認証後にユーザーがリダイレクトされるアプリケーションURLを入力します。
    3. Web層のポリシー構成はスキップします。
    アプリケーションが作成されます。
  2. 「アクティブ化」をクリックして、アプリケーションをアクティブ化します。
  3. 「一般情報」「クライアントID」および「クライアント・シークレット」の値を書き留めます。
  4. 「ユーザー」をクリックし、アプリケーションにユーザーを割り当てます。Oracle Cloud Infrastructureドキュメントカスタム・アプリケーションへのユーザーの割当てを参照してください。
  5. ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「アイデンティティ」で、「ドメイン」をクリックします。作業するアイデンティティ・ドメインを選択します。
    アイデンティティ・ドメインの「ドメイン情報」タブが表示されます。
  6. このタブから、「ドメインURL」をコピーします。たとえば、https://idcs-a83e4de370ea4db1b8c703a0b742ce74.identity.oraclecloud.comです。検出URLを実行する際にこの情報が必要になります。
  7. 署名証明書のクライアント・アクセスを有効にします。デフォルトでは、アクセスはサインイン・ユーザーのみに制限されています。Docker、KubernetesおよびIstioでこの証明書にアクセスするには、クライアント・アクセスを有効にする必要があります。
    1. 作業するアイデンティティ・ドメインを選択し、「設定」「ドメイン設定」の順にクリックします。
    2. 「署名証明書へのアクセス」のスイッチをオンにして、クライアントがIAMにログインせずにテナントの署名証明書にアクセスできるようにします。
    3. 「保存」をクリックしてデフォルト設定を保存します。
    4. ログインせずに証明書にアクセスできるかどうかを確認するには、新しいブラウザ・ウィンドウで次のリンクを入力します。
      https://<yourtenant>.identity.oraclecloud.com/admin/v1/SigningCert/jwk

      ここで、<yourtenant>はOracle Cloud Infrastructureテナンシの詳細です。

      Oracle Cloud Infrastructureにログインせずにリンクを開くことができるはずです。

3.3.2.2 アイデンティティ・プロバイダとしてのOracle IDCSの使用

Oracle IDCSをアイデンティティ・プロバイダとして使用し、アプリケーションへのアクセスを管理できます。

  1. Oracle Cloud Infrastructureコンソールで、アプリケーションを機密アプリケーションとして追加します。『Oracle Identity Cloud Serviceの管理』機密アプリケーションの追加を参照してください。

    機密アプリケーションを追加する際に、次のタスクを実行します:

    1. 機密アプリケーションの追加ウィザードの「クライアント」ページで、「今すぐこのアプリケーションをクライアントとして構成します」をクリックします。
    2. 「認可」セクションで、次のオプションを選択します:
      • リソース所有者
      • クライアント資格証明
      • JWTアサーション
      • リフレッシュ・トークン
      • 認可コード
      • リダイレクトURL: 認証後にユーザーがリダイレクトされるアプリケーションURLを入力します。
    3. 次のステップをスキップします。デフォルトの選択肢を使用して、「終了」をクリックします。アプリケーションが非アクティブ状態で追加されます。
    4. 「アプリケーションが追加されました」ダイアログ・ボックスに表示される「クライアントID」および「クライアント・シークレット」を書き留めます。この情報は後で指定する必要があります。
    5. 「閉じる」をクリックします。

      新しいアプリケーションの詳細ページが表示されます。

    6. ページ上部のアプリケーション名の右にある「アクティブ化」をクリックして、アプリケーションをアクティブ化します。
    7. 「アプリケーションをアクティブ化しますか。」ダイアログ・ボックスで、「アプリケーションのアクティブ化」をクリックします。
  2. 「ユーザー」をクリックし、アプリケーションにユーザーを割り当てます。『Oracle Identity Cloud Serviceの管理』ユーザー・アカウントへのアプリケーションの割当てを参照してください。
  3. 署名証明書のクライアント・アクセスを有効にします。デフォルトでは、アクセスはサインイン・ユーザーのみに制限されています。クライアントがOracle Identity Cloud Serviceにログインせずにテナント署名証明書およびSAMLメタデータにアクセスできるようにするには、次のステップを実行します。
    1. Identity Cloud Serviceコンソールでナビゲーション・ドロワーを開き、「設定」「デフォルト設定」の順に選択します。
    2. 「署名証明書へのアクセス」オプションをオンにします。
    3. 「保存」をクリックしてデフォルト設定を保存します。

3.3.3 検出URLの実行

アイデンティティ・プロバイダを設定した後、任意のブラウザで検出URLを実行して、認証のためにvalues.yamlファイルに指定する必要がある値を書き留めます。

詳細は、『Oracle Identity Cloud Service REST API』トークン検証を参照してください。
検出URLを実行して必要な情報を書き留めるには:
  1. 任意のブラウザで検出URLを実行します。

    検出URLの構文

    https://<tenant-base-url>/.well-known/openid-configuration

    検出URLの例

    https://idcs-a83e4de370ea4db1c703a0b742ce74.identity.oraclecloud.com/.well-known/openid-configuration
    値のリストが表示されます。
  2. issuerフィールドおよびjwksUriフィールドの値を書き留めます。これらの値をvalues.yamlファイルに指定する必要があります。たとえば:
    issuer: "https://identity.oraclecloud.com"
    jwksUri: "https://idcs-a83e4de370ea4db8c703a0b742ce74.identity.oraclecloud.com:443/admin/v1/SigningCert/jwk"
  3. audienceの値を書き留めます。

3.3.4 アクセス・トークンの作成

このトピックでは、アイデンティティ・プロバイダとしてOracle IDCSまたはOracle IAMを使用する場合にアクセス・トークンを作成するための詳細を示します。

KeycloakまたはMicrosoft ADをアイデンティティ・プロバイダとして使用する場合は、アイデンティティ・プロバイダの設定およびアクセス・トークンの作成の詳細について製品ドキュメントを参照してください。

サービスに対するAPIコールは、有効な認証トークンが必要です。アクセス・トークンを作成します。これは、サービスに対する後続のAPIコールで指定できます。アクセス・トークンの他に、サービスに対する後続のAPIコールでリフレッシュ・トークンを指定することもできます。MicroTxは、リフレッシュ・トークンを使用して期限切れのアクセス・トークンをリフレッシュします。

開始する前に、アイデンティティ・プロバイダを設定したことと、クライアントID、クライアント・シークレットおよびドメインURLの値を書き留めたことを確認します。
  1. ターミナルを起動し、次のコマンドを入力します。
    echo -n "clientid:clientsecret" | base64 -w 0 

    ここで、clientid:clientsecretを環境の値で置き換えます。-w 0は、改行を削除するためにLinuxの場合にコマンドに追加されます。

    クライアントIDおよびクライアント・シークレットのbase64エンコードされた値が返されます。この値は後で指定する必要があるため書き留めておきます。

    環境に応じて、任意のbase64クライアントを使用してclientid:clientsecretをエンコードできます。

  2. 返された値をコピーします。この値は認証トークンを作成するたびに指定する必要があります。
  3. 次のcURLコマンドの例に示すように、base64エンコードされた値を使用して認証トークンを取得します。アクセス・トークンのみを生成するか、リフレッシュ・トークンも生成するかに応じて、次のいずれかのコマンドを実行します。
    • 次のコマンドによってアクセス・トークンが作成されます。

      コマンド構文

      curl -i 
      -H "Authorization:Basic {base64 encoded value of clientid:clientsecret}"
      -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8"
      --request POST https://domain-url/oauth2/v1/token
      -d "grant_type=password&username=username&password&scope=urn:opc:idm:__myscopes__"
      

      curl -i 
      -H "Authorization:Basic ZWY1N2E1OWUyZjY..."
      -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8"
      --request POST https://idcs-a83e4de370ea4db1b8c703a0b742ce74.identity.oraclecloud.com/oauth2/v1/token
      -d "grant_type=password&username=acme@example.com&password&scope=urn:opc:idm:__myscopes__"
    • 次のコマンドによってアクセス・トークンとリフレッシュ・トークンが作成されます。

      コマンド構文

      curl -i 
      -H "Authorization:Basic {base64 encoded value of clientid:clientsecret}"
      -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8"
      --request POST https://domain-url/oauth2/v1/token
      -d "grant_type=password&scope=urn:opc:idm:__myscopes__+offline_access&username=username&password=password"

      curl -i 
      -H "Authorization:Basic ZWY1N2E1OWUyZjY..."
      -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8"
      --request POST https://idcs-a83e4de370ea4db1b8c703a0b742ce74.identity.oraclecloud.com/oauth2/v1/token
      -d "grant_type=password&scope=urn:opc:idm:__myscopes__+offline_access&username=acme@example.com&password=password"
  4. 次の例に示すように、レスポンスのaccess_token値をコピーします。

    出力例

    {
      "access_token":"eyJ4Lm...",
      "expires_in": 300,
      "refresh_expires_in": 1800,
      "refresh_token": "ey5Gkr...",
      "token_type": "Bearer",
      "not-before-policy": 0,
      "session_state": "c966d...",
      "scope": "profile email"
    }
    

    レスポンス例は、読みやすくするために省略記号(...)を使用して一部を省いています。

    実際のトークンのみ(引用符に囲まれたaccess_token値とrefresh_token値)をコピーするようにしてください。

  5. 次のLinuxホストの例に示すように、認証トークンおよびリフレッシュ・トークンを環境変数に格納します。
    export TOKEN="eyJ4Lm..."
    export REFRESH_TOKEN="ey5Gkr..."
  6. 次のLinuxホストの例に示すように、認証cookieを環境変数に格納します。
    export OTMM_COOKIE="eyJh...x_THw"

    値の例は、読みやすくするために省略記号(...)を使用して一部を省いています。

OAuth 2.0トークンを取得した後、サービスに対する後続のAPIコールを作成するときに、authorizationおよびrefresh-tokenヘッダーのトークンを使用します。