OpenID Connect アプリケーションでのシングル・サインオンの構成
OpenID Connect を使用すると、 IBM® Verifyによる認証応答コールバックに基づいて、ユーザーのアプリケーション ID 検証を行うことができます。 さらに、ユーザーはアプリケーションでアカウントを登録する必要がありません。 ユーザーは、ログインのために Verify にリダイレクトされます。 Verifyは、ユーザーの ID を検査し、ID トークンを介して情報を送信し、ユーザーがリソースへのアクセスと使用を許可されていることを依拠当事者に確認します。 このアプリケーションは、ディスカバリー・エンドポイント https://<tenant-host>/oauth2/.well-known/openid-configurationを持つ新しい OpenID Connect プロバイダーを使用します。
始める前に
- このタスクを完了するには管理者権限が必要です。
- 少なくとも 2 つのブラウザー・ウィンドウを開いて、セットアップを完了します。 1 つは Verify 管理コンソール用で、もう 1 つはターゲット・アプリケーションの管理コンソール用です。
- Verify 管理コンソールにログインします。
- 管理者アカウントでターゲット・アプリケーション管理コンソールにログインします。
- 一般タブで、アプリケーション・インスタンスの基本情報をセットアップする必要があります。 基本アプリケーションの詳細設定を参照してください。
このタスクについて
アプリケーションを検査する際は、 Connect テンプレートを選択し、アプリケーションをConnect OpenIDOpenID の依存先として動作させるか、ユーザーの認証をConnectに委任するクライアントアプリケーション Verifyとして動作させるように構成します。
Verifyと依拠当事者が相互に対話するように構成します。 OpenID Connect シングル・サインオンを有効にするには、以下を指定する必要があります。
- 依拠当事者からの特定のデータを含むVerify。
- Verifyからの特定のデータを持つ依拠当事者。
IBM Verify Accessおよびモバイル・アプリケーションを OpenID Connect リライング・パーティーとして構成できます。
手順
- 依拠当事者に関する基本情報を検証に提供します。
フィールド 説明 URL これは OpenID の依拠当事者にログインするために使用されるシングルサインURL です。
アプリケーションは、この URL を使用して、ユーザーの詳細が含まれている ID トークンを Verify に要求します。
ユーザーがこの URL を介してアプリケーションにアクセスすると、ユーザーは認証のために Verify にリダイレクトされます。
この情報は、許可プロバイダー または OpenID Connect プロバイダー をそのサイトで構成するときに、依拠当事者 から取得できます。
付与タイプ これは、 依拠当事者 が Verifyから ID トークンを取得するために使用できるメカニズムを示します。
OpenID Connect は、以下の付与タイプをサポートします。- 許可コード
- 暗黙的
- デバイス・フロー
- クライアント資格情報
- 許可コードと暗黙的 (ハイブリッド・フロー)
- リソース所有者パスワード資格情報 (ROPC)
- トークン交換
- JWT ベアラー
- コンテキスト・ベースの許可
少なくとも 1 つの付与タイプを選択する必要があります。 グラントの種類を参照して、サポートされているグラントの種類を簡単に比較し、アプリケーションに設定するグラントの種類を決定してください。
応答タイプ 応答タイプは、必要な許可処理フローを許可サーバーに通知します。 注: 応答タイプが構成されていない既存のアプリケーションを編集する場合、デフォルトでは、有効にされた付与タイプに適用されるすべての応答タイプになります。OpenID Connect は、以下の応答タイプをサポートします。nonecodetokenid_tokencode tokencode id_tokentoken id_tokencode token id_token
応答タイプ
codeまたはnoneが選択されている場合、応答モードqueryが有効になります。 それ以外の場合、応答モードqueryはクリアされ、使用不可になります。応答モード 応答モードは、Authorization Server が許可エンドポイントから結果パラメーターを返す方法を示します。 OpenID Connect は、以下の応答モードをサポートします。- 照会
- 断片
- フォーム POST
- JWT の照会
- フラグメント JWT
- フォーム POST JWT
クライアント ID これは、 クライアント・アプリケーション( OpenID Connect 依拠当事者) に割り当てられる固有の公開 ID です。 許可サーバーはこの情報を使用して、依拠当事者と許可要求を識別します。
この情報は、 OpenID Connect アプリケーションを保存した後に自動的に生成されます。 アプリケーションの管理コンソールでVerifyを OpenID Connect プロバイダーとして構成する場合は、この情報を依拠当事者に提供する必要があります。
依拠当事者は、アクセス・トークンを要求するたびにクライアント ID を使用します。
パブリック・クライアント (クライアント秘密鍵なし) アプリケーションが提供する必要がある秘密鍵がクライアントにないことを示します。
クライアント秘密鍵を生成するのは、クライアント・タイプが機密の場合のみです。 機密クライアントは、クライアント ID とクライアント秘密鍵をセキュアな方法で保持でき、これらの資格情報を無許可の関係者に表示することはありません。
クライアント・シークレットは、クライアント・アプリケーションと許可サーバーにのみ認識される必要があります。
注: このオプションを選択すると、 「クライアント・シークレット」 フィールドは非表示になります。クライアント秘密鍵 このデータは、依拠当事者を認証し、ID トークンの許可コードを交換するために、クライアント ID とともに使用されます。
この情報は、 OpenID Connect アプリケーションを保存した後に自動的に生成されます。 アプリケーションの管理コンソールでVerifyを OpenID Connect プロバイダーとして構成する場合は、この情報を依拠当事者に提供する必要があります。
リダイレクト URI (Redirect URIs) * これはコールバック URL であり、Verifyがその認証応答を依拠当事者に送信するアドレスです。
ユーザーは、Verify によって認証および許可された後、この URL にリダイレクトされます。
少なくとも 1 つの URI を指定する必要があります。
最大 400 個の URI を追加できます。
この情報は、サイトで許可プロバイダーまたは OpenID Connect プロバイダーを構成するときに、依拠当事者から取得できます。
クライアント認証方式 Verify は、以下のクライアント認証方式をサポートしています。- デフォルト
- クライアント秘密鍵 Basic
- クライアント秘密鍵 POST
- 秘密鍵 JWT
- 相互TLS
注: デフォルトのクライアント認証方式は defaultです。デフォルトのままにした場合、クライアント秘密鍵 Basic と POST の両方が許可されます。 このクライアントがパブリック・クライアントの場合、クライアント・シークレットの基本と POST は許可されません。 依拠当事者がサポートしている場合は、構成として秘密鍵 JWT または相互 TLS を使用します。 相互TLSクライアント認証の詳細については、 「相互TLSクライアント認証と証明書に紐づけられたアクセストークンの接続」 を OpenID 参照してください。
クライアント・アサーション JTI の検証 (Validate client assertion JTI) クライアント・アサーション JWT 内の JTI が単一使用に対して検証されるかどうかを示します。 このオプションは、秘密鍵 JWT クライアント認証方式が選択されている場合にのみ表示されます。
クライアント・アサーション署名アルゴリズム * * このオプションは、 秘密鍵 JWT クライアント認証方式が選択されている場合にのみ表示されます。
TLS クライアント認証属性 認証に使用される証明書属性です。 このオプションは、相互 TLS クライアント認証方式が選択されている場合にのみ表示されます。 - サブジェクト DN
- SAN DNS
- SAN URI
- SAN IP
- SAN E メール・アドレス
TLS クライアント認証属性値 * 認証に使用される証明書内の属性の値です。 このオプションは、相互 TLS クライアント認証方式が選択されている場合にのみ表示されます。 Proof Key for Code Exchange (PKCE) の検証が必要 PKCE は、許可コード傍受攻撃を軽減するために使用されます。 これは、許可コード・フローの続行前に、コードのチャレンジを必要とします。 このオプションが表示されるのは、許可コードの付与フローを選択したときのみです。 プッシュされた許可要求 (PAR) が必要 PAR により、クライアントは、許可要求のペイロードを直接要求を介して許可サーバーにプッシュし、許可エンドポイントへの後続の呼び出しでデータへの参照として使用される要求 URI を許可サーバーに提供することができます。 SSO セッションでのアクセス・トークンの交換を許可する SSO セッション用のアクセス・トークンの交換。 - 許可: SSO セッションでアクセス・トークンを交換できます。
- トークンの許可および取り消し: SSO セッションでアクセス・トークンを交換できますが、トークンは取り消されます。
- 拒否: SSO セッションでアクセス・トークンを交換できません。
- デフォルト: OIDC アプリケーションの一般設定は、SSO セッションでアクセス・トークンを交換できるかどうかを決定します。
既存のアプリケーションを編集する場合は、次のクライアント秘密鍵オプションを使用できます。- クライアント秘密鍵を表示するには、
を選択します。 - クライアント秘密鍵を非表示にするには、
を選択します。 - クライアントIDまたはシークレットをクリップボードにコピー
するには、[選択]をクリックしてください。 - 回転したクライアントシークレットを表示
するには、[選択]をクリックしてください。- リストから 1 つまたは複数のローテートされたクライアントシークレットを選択し、[削除]をクリックして削除します。
- 新規クライアント・シークレットを生成するには、
を選択します。 クライアント秘密鍵が漏えいしたと思われる場合は、このオプションを使用します。 クライアント秘密鍵を再生成した場合は、アプリケーションのすべての OAuth クライアントにあるクライアント秘密鍵を更新する必要があります。- 現在の秘密を保持する]のチェックボックスを選択すると、現在のクライアント秘密がローテートされたクライアント秘密のリストに追加されます。
- 現在のシークレットを保持する]チェックボックスが選択されている場合、クライアントシークレットの説明と有効期限（ブラウザのローカル時間）を選択します。 有効期限が選択されていない場合、アプリケーション設定で設定されたテナントの「ローテーションされた秘密の有効期限」が適用されます。
- ローテーションされたクライアント秘密はハッシュ化され、プレーンテキストでは取得できなくなりますが、選択された有効期限まで使用することができます。
- 確認後、クライアント秘密は直ちにローテートされる。 新しいクライアントシークレットが画面に表示されます。
- ユーザーがアプリケーションにアクセスする方法を決定する ID プロバイダーとポリシーを選択します。
- ユーザーがアプリケーションにアクセスする方法を決定するポリシーを選択します。割り当てられているデフォルトのアクセス・ポリシーを引き続き使用できます。 代わりに、チェックボックスをオフにし、[事前定義済みアクセスポリシー] リストから選択する
オプションを選択することもできます。 詳細については、 アクセスポリシーを参照してください。 アクセス・ポリシーが選択されている場合、各権限付与タイプのチェック・ボックスを選択して、API 権限付与タイプにアクセス・ポリシーを適用することを選択します。
- ユーザーがアプリケーションにアクセスする方法を決定するポリシーを選択します。
次の手順
- 依拠当事者 に、 Verify と 依拠当事者の間の OpenID Connect サインオン構成を完了するために必要な Verify に関する情報を提供します。 ユーザー・インターフェースで提供されている説明を参照してください。
- 構成済みアプリケーションへのアクセスを許可するユーザーまたはグループの資格を追加します。 アプリケーションの権限管理（管理者またはアプリケーション所有者による） を参照してください。
- ユーザーに対するセキュリティー管理を強化するために、ユーザーが構成済みアプリケーションにサインオンする際に、2 要素認証を実施します。 認証要素の設定を参照してください。
- このアプリケーションに API クライアントを追加します。 「Connect」および OpenID 「Connect for Open OpenID Banking」アプリケーションのAPIアクセスについては、「Connect」の管理を参照してください。
- このアプリケーションのプライバシー目的と EULA を構成します。 参照： OpenID Connect